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 Service Bus. Вижте отговора ми в следния въпрос:

WCF, 4.0, двупосочен

person Shiraz Bhaiji    schedule 09.05.2010

Разгледайте Windows AppFabric, добро място да започнете е тук. Той основно обгръща WCF и WF в сървър за приложения, като WCF активирането се поддържа чрез WAS. Там бих хоствал този тип приложение. Той предлага пълна дуплексна връзка, ориентирана към p2p или сесии между клиент и сървър. Не бъркайте Windows appfabric с Azure appfabric (по-рано наричан Azure Service Bus).

Що се отнася до обвързванията по-горе, както NetTcpBinding, така и WsDualHttp предлагат обратни извиквания, но обвързването на ws получавате много за парите си, особено ако това е среда за смесено програмиране и трябва да изравните wsdl, за да работи interop. Също така смятам, че WsDual е по-лесен за преминаване през рутери, въпреки че разбирам, говорейки с приятели, че Windows AppFabric смекчава това с нови Relay Services (които не съм виждал и мисля, че вече са преименувани).

Надявам се това да помогне.

person scope_creep    schedule 10.05.2010