Просто технологична актуализация, след като .NET 4.0 вече е на пазара.
Пиша приложение, което комуникира със сървъра чрез това, което всъщност е автобус за съобщения (вместо извиквания на метод). Това се основава на вътрешната архитектура на приложението (което е многопоточно, предавайки съобщенията наоколо).
Има ограничен брой съобщения за преминаване от клиента към сървъра, много повече от сървъра към клиента. Повечето от тях могат да се обработват чрез отделен специализиран механизъм, но в крайна сметка говорим за евентуално 10-100 малки съобщения в секунда, преминаващи от сървъра към клиента.
Клиентът трябва да работи при "интернет условия". Това означава вероятно домашни крайни потребители зад стандартни NAT устройства (т.е. типични DSL рутери) - защитена със защитна стена и следователно "отворена" мрежа не може да се приеме.
Искам да имам възможно най-малко забавяне и възможно най-малко излишни разходи за комуникация.
Кой е технологично най-добрият начин за обработка на обратното извикване на шината за съобщения? Нямам проблем да се обаждам редовно на сървъра за доставка на съобщение, ако нещо трябва да бъде изпратено... ...но какви са възможностите ми да обработвам съобщенията от сървъра до клиента?
- WsDualHttp работи как? Особено при NAT сценарий?
Само като забележка: анкетирането най-вероятно е изчерпано - основният проблем тук е, че ще имам значителни разходи ИЛИ значително забавяне, и двете не са наистина желани. Технически бих се радвал на някакъв подход за стрийминг, при който сървърът може да пише съобщения в поток, докато ги генерира, и те се изпращат на клиента, когато пристигнат. Не съм сигурен обаче, че това е изпълнимо с WCF (ако не, може да реша да обработя цялата част на съобщението извън WCF и просто да направя контрол/влизане/настройка/унищожаване чрез WCF).