4.0/WCF: лучший подход для двунаправленной шины сообщений?

Просто технологическое обновление, теперь, когда вышла версия .NET 4.0.

Я пишу приложение, которое взаимодействует с сервером через шину сообщений (вместо вызовов методов). Это основано на внутренней архитектуре приложения (многопоточное, передающее сообщения).

От клиента к серверу передается ограниченное количество сообщений, от сервера к клиенту гораздо больше. Большинство из них можно обработать с помощью отдельного специализированного механизма, но в конце мы говорим о 10-100 небольших сообщениях в секунду, передаваемых от сервера к клиенту.

Клиент должен работать в "условиях интернета". Это означает, что, возможно, домашние конечные пользователи находятся за стандартными устройствами NAT (т. е. типичными маршрутизаторами DSL) — защищенная брандмауэром и, следовательно, «открытая» сеть не может быть принята.

Я хочу иметь как можно меньше задержек и как можно меньше перегрузок для связи.

Каков технологически лучший способ обработки обратного вызова шины сообщений? У меня нет проблем с регулярным обращением к серверу для доставки сообщений, если что-то нужно отправить... ...но каковы мои варианты обработки сообщений от сервера к клиенту?

  • Как работает WsDualHttp? Особенно по сценарию NAT?

Просто в качестве примечания: опрос, скорее всего, отсутствует - основная проблема здесь в том, что у меня будут значительные накладные расходы ИЛИ значительная задержка, и то, и другое на самом деле не нужно. Технически мне бы хотелось использовать какой-то потоковый подход, когда сервер может записывать сообщения в поток, пока он их генерирует, и они отправляются клиенту по мере их поступления. Не уверен, что это выполнимо с WCF (если нет, я могу решить обработать всю часть сообщения вне WCF и просто выполнить управление/вход/настройку/уничтожение через WCF).


person TomTom    schedule 20.04.2010    source источник
comment
Попробуйте взглянуть на методы COMET. Обычно они включают отправку запроса от клиента, а затем сервер удерживает сокет открытым, пока не получит ответ. Однако большинство реализаций сосредоточены на своевременном уведомлении о событиях, а не на непрерывном потоке обновлений.   -  person Gareth Saul    schedule 20.04.2010


Ответы (3)


Для двунаправленной связи лучше всего использовать NetTcpBinding, а не привязки http, если они доступны.

Это имеет то преимущество, что требуется только то, чтобы клиент мог инициировать соединение с сервером.

person kyoryu    schedule 09.05.2010

Я бы выбрал служебную шину Windows Azure. См. мой ответ в следующем вопросе:

WCF, 4.0, двунаправленный

person Shiraz Bhaiji    schedule 09.05.2010

Взгляните на Windows AppFabric, хорошее место для начала — здесь. По сути, он объединяет WCF и WF в сервер приложений, а активация WCF поддерживается через WAS. Здесь я бы разместил приложение такого типа. Он предлагает полнодуплексное соединение, ориентированное на p2p или сеансы между клиентом и сервером. Не путайте фабрику приложений Windows с фабрикой приложений Azure (ранее называвшейся служебной шиной Azure).

Что касается приведенных выше привязок, то и NetTcpBinding, и WsDualHttp предлагают обратные вызовы, но привязка ws дает много денег, особенно если это смешанная среда программирования, и вам нужно сгладить wsdl, чтобы заставить взаимодействие работать. Я также думаю, что WsDual проще при обходе маршрутизаторов, хотя я понимаю, что, разговаривая с друзьями, Windows AppFabric смягчает это с помощью новых служб ретрансляции (которые я не видел, и я думаю, что они теперь были переименованы).

Надеюсь, это поможет.

person scope_creep    schedule 10.05.2010