za nettcpbinding moras znati ogranicenja i da li se to uklapa u tvoju zamisljenu arhitekturu sistema. svi klijenti moraju biti .net, znaci nema interoperabilnosti. posto koristis .net 4, verujem da ces wcf server da hostujes u IIS 7.5 / WAS / Wind Server App Fabric. Nettcpbinding podrzava duplex komunikaciju ako ti to treba, sto je u prirodi tcp protokola. Ako ces da koristis HTTP protokol, a treba ti duplex, onda koristi ovaj koji si naveo, s tim da ti interoperabilnost uopste nije zagarantovana

Nemoj ni da pokusavas osim ako u nekom scenariju klijent moze da prima inbound konekcije sto u vecini slucajeva blokira firewall.

Meni je trebala Dual konekcija ali sam to simulirao obicnim basic binding-om. a klijent radi subscribe na poruke na blokirajucoj wcf servisnoj metodi koja je ustvari named pipe koji ceka poruku
i tako sto ceka neko odredjeno vreme na poruku ako je ne dobije onda zatvara konekciju (named pipe) i otvara novu konekciju tj. subscribe koji ustvari ne mora ni biti blokirajuci poziv vec asinhroni sa callback handler-om .
Druga strana salje poruku kroz drugu servisnu metodu (notify) tj. named pipe koji ceka i na isti nacin komunicira i jedna i druga strana ....

hehe, to je mehnizam koji koristi ActiveSync DirectPush, moras da platis licencu MSu

Gde je MS objavio sta mu se krije ispod haube ? Inace nisam ni konsultovao ActiveSync DirectPush vec sam iskoristio jedino sto mi je preostalo

ovde

al ne brini, nisi jedini koji ne haje za njihov patent gmail koristi isti mehanizam da syncuje svoj inbox.

Interoperabilnost me ne interesira... U svakom slučaju bi morao dodati exception u firewall kod svih klijenata, zar ne?
WCF bi bio self hosted u windows serviceu...
U svakom slučaju počinjem razmišljati da mi ovo uopće niti ne funkcionira preko duplexa već kao jednosmjerna veza, ustvari mi je bilo samo bitno obavijestiti ostale klijente kad je neki od ostalih klijenata napravio neku akciju i po samoj definiciji mi je odmah duplex pao na pamet.

Posljednjih par dana mi se baš sve više i više motalo po glavi ovo riješenje od deerbera, bez da sam i pročitao ovaj post, ali mi je to djelovalo ko izmišljanje tople vode, sad mi se čini sve izvjesnije da ću baš to i koristiti

Direct push je dobar mehanizam samo ima par sitnica koje mogu da ti pokvare dan.

1. Imaj plan na klijentu za situaciju kad server nije dostupan, poimence razlikuj tu situaciju od one u kojoj je konekcija izbacila timeout po dizajnu i kad izbaci zato sto je host unreachable ili je neka od usputnih mreznih komponenti dropovala konekciju. Moze da ti se desi da jednostavno uletis u petlju i krenes da floodujes server. Ovo je najlase resiti minimalnim razmakom izmedju dva ovaranja konekcije (a koji je manji od tvog planiranog timeout-a)
2. Adaptiraj se i nemoj pretpostaviti da je timeout koji si ti postavio na klijentu onaj koji ce biti realizovan u praksi. Npr NAT admin moze da podesi timeout na port-mapping koji je dosta kraci pa ce ti konekcija pasti.
3. Ne ocekuj da ces dobiti notifikaciju o zatvorenoj konekciji u slucaju #2 :) Network admini vole da samo cutke dropuju :) pa ti cekaj i susi se.

Iz gornjih razloga imaj two-part komunikacioni protokol. Tu long-lived konekciju koristi samo kao flag da je nesto spremno na serveru i onda iskoristi poll metod da povuces konkretne podatke. Ako podatke vracas istom konkecijom iz razloga #2 moze cak da ti se desi da ti konekcija padne usred receiva.

hvala puno, dobio sam puno korisnih informacija... Idem onda sa jednosmjernom vezom...