Hi list I just give you a quick update on this..
>>PeterG: WCF net.tcp protocol in Silverlight 4 (Polling over TCP Sockets) I have to correct my self here. This is not the case, WCF is not polling over TCP sockets, but keeping a socket open and using that to send and receive messages... awesome performance... Initially I started typing up an email, then I was thinking: Hey put this on your blog and get some traffic on it... So here is the blog post http://peitor.blogspot.com/2010/03/time-communication-clientserver.html Content here -------- We are building something similar and have the following *requirements* 1. People on the *web* should be able to use it 2. *No download* of an application 3. *Broadcasting* messages to all user (server to clients) 4. Everyone should be able to use it 1. People behind *firewalls*, proxies, NATs, … 2. People with 1 of the *current browsers* 5. *Lightweight* solution needed We tested and verified different technology options like: - HTML+ Reverse AJAX - Silverlight 2: Duplex WCF over HTTP (Long polling HTTP connection under the hood or Comet-style) - Silverlight 4: Duplex WCF over TCP (is using net.tcp, socket connection under the hood) - Silverlight raw Sockets (maybe even using SocketsLight<http://www.silverlightshow.net/items/SocketsLight-Silverlight-Sockets-Framework.aspx> ) - Silverlight UDP - HTML 5 web sockets The signs for HTML 5 web sockets are not so good, even though the promise for the socket implementation sounds interesting! But it seems that HTML 5 is not going to be ready before ~201X, X > 2 and not sure what that X is… More here http://blogs.techrepublic.com.com/programming-and-development/?p=718 http://www.webmonkey.com/blog/HTML_5_Won_t_Be_Ready_Until_2022DOT_Yes__2022DOT We finally are using "*Silverlight* with Duplex *WCF over TCP*” And falling back to "*Silverlight* with Duplex* WCF over HTTP*” when we have a firewall or proxy in the middle that causes connection problems. The main reason for going in that direction was: - *Ease of development* and *productivity* in coding with Silverlight and WCF - Developing against *one API *(WCF) and doing an easy fallback behind the scenes (10 lines of code!) - *Performance* is awesome by using TCP (see Tomasz post<http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html> about that) - *Testing* Silverlight means testing 1 environment against testing different browsers, operating systems, JavaScript versions, OS versions, browser versions,.... PS There is a new HTTP polling duplex mode<http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html> added in Silverlight 4 RC, called “MultipleMessagesPerPoll”, makes this technology even more interesting .peter.gfader. http://peitor.blogspot.com/ http://twitter.com/peitor On Thu, Jan 28, 2010 at 7:10 PM, Peter Gfader <[email protected]>wrote: > >>In Silverlight 3 didn’t they introduce a duplex WCF service? > > Yes they introduced duplex WCF services, *but* it is doing "long" polling > under the hood... > > Messages from the server to the client within a particular session are sent > using an HTTP response to a* long lasting HTTP request* the client makes > to the server (the “long poll”). > The client side implementation of the polling duplex protocol ensures that > the server always has such pending HTTP request available; as soon as the > server sends a message to the client using the response to the long poll, > the client issues a new long poll. > > From > > > http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html > > > > .peter.gfader. > http://peitor.blogspot.com/ > > On Thu, Jan 28, 2010 at 4:17 PM, John OBrien <[email protected]>wrote: > >> Peter, >> >> We used sockets in Silverlight2 to prototype a spatial collaboration >> concept. The main issues we faced were: >> >> 1. Needed to run a windows application (testing=console app, >> production=windows service) for both server side processing and also as a >> policy service. Made it hard to deploy. >> >> 2. Very raw technology, we had to deal with packets of data and >> worried about robustness of the server solution under heavy load. >> >> >> >> In the end we didn’t move beyond the prototype but decided we need to >> evaluate the purchase of a socket based communication server (often used for >> online games). >> >> >> >> In Silverlight 3 didn’t they introduce a duplex WCF service? >> >> >> >> John. >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Peter Gfader >> *Sent:* Thursday, 28 January 2010 1:33 PM >> *To:* [email protected] >> *Subject:* "Real" time updates to and from clients >> >> >> >> Hi All, >> >> >> >> I play around with "real time" updates to and from SL clients, and have >> figured out a couple of possibilities with Silverlight. >> >> 1. Sockets >> 2. Polling over WCF in SL2 or SL3 (HTTP) >> 3. WCF net.tcp protocol in Silverlight 4 (Polling over TCP Sockets) >> >> Anyone has some good or bad experience with them? >> >> >> >> Regarding >> >> 1. Performance >> 2. Ease of development >> 3. Security (Firewalls are not a problem) >> >> >> >> My opinion so far: >> >> 1. Sockets >> >> >> 1. Harder to write than calling a WCF service >> 2. Best option regarding performance >> >> >> 1. Polling over WCF (HTTP) >> >> >> 1. Not a nice solution regarding performance >> >> >> 1. WCF net.tcp protocol in Silverlight 4 (Polling over TCP Sockets) >> >> >> 1. Under the hood sockets, but I don't have to worry about sockets >> 2. Good performance >> >> Port restrictions to all of those I have seen... >> >> >> >> Your opinions? >> >> >> >> PS >> >> This guy has a nice Socket implementation for getting updates from a >> server >> >> http://petermcg.wordpress.com/2008/06/05/stock-list-demo-part-3/ >> >> >> >> This guy is writing about WCF net.tcp in SL 4 >> >> >> http://tomasz.janczuk.org/2009/11/wcf-nettcp-protocol-in-silverlight-4.html >> >> >> >> >> PS2 >> >> What can I do against port restrictions? >> >> >> >> .peter.gfader. >> >> http://peitor.blogspot.com/ >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> ozsilverlight mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >> >> >
_______________________________________________ ozsilverlight mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
