Просто обновление технологии, теперь, когда вышел .NET 4.0.
Я пишу приложение, которое связывается с сервером через то, что в основном является шиной сообщений (вместо вызовов методов). Это основано на внутренней архитектуре приложения (которая является многопоточной, передавая сообщения).
Количество сообщений от клиента к серверу ограничено, от сервера к клиенту гораздо больше. Большинство из них могут обрабатываться с помощью отдельного специализированного механизма, но в конце мы говорим о 10-100 маленьких сообщениях в секунду, идущих от сервера к клиенту.
Клиент должен работать в «интернет-условиях». Это означает, что, возможно, домашние конечные пользователи за стандартными устройствами NAT (то есть типичными DSL-маршрутизаторами) - защищенная сеть, защищенная брандмауэром, и, следовательно, «открытая» сеть не может быть принята.
Я хочу, чтобы задержка была как можно меньше, а коммуникация была как можно меньше.
Каков технологически лучший способ обработки обратного вызова шины сообщений? У меня нет проблем регулярно звонить на сервер для доставки сообщений, если что-то нужно отправить ...
... но каковы мои варианты обработки сообщений от сервера к клиенту?
- WsDualHttp работает как? Особенно по сценарию NAT?
Так же, как примечание: опрос, скорее всего, закончился - главная проблема здесь в том, что у меня были бы значительные накладные расходы ИЛИ существенная задержка, и то, и другое не очень хотелось. Технически я хотел бы получить потоковую аппроксимацию, где сервер может записывать сообщения в поток, пока он их генерирует, и они отправляются клиенту по мере их поступления. Не уверен, что это выполнимо с WCF, хотя (если нет, я могу на самом деле решить обработать всю часть сообщения вне WCF и просто сделать управление / вход в систему / настройка / уничтожение через WCF).