Thanks for that. Those articles cover the topic well. I had figured out that was an issue for Silverlight 3 / WCF when in a hobby project I implemented a turn based game server (eg live chess) using duplex wcf. I had pondered whether my implementation would scale out, and had concluded it would not without a change in approach.
I was actually wondering if polling over sockets might help address that issue , as perhaps a particular client would have affinity with the initial server to which the socket was established? Or is that not the case? Assuming there is affinity with sockets, I suppose that leaves two options : 1. Some sort of shared state between the servers, as suggested by those articles. With the incumbent performance loss. or 2. Once a 'chat' between two clients is being negotiated, both clients could be forced onto the same server (assuming that is possible). On , Peter Gfader <[email protected]> wrote: > Hi > > >> Do you know, does "Silverlight 4: Duplex WCF over TCP" have any > >> issues with server affinity in a web farm / load balancing configuration? > > > > Yes this issue is there > > > from > http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html > > Current implementation of polling duplex protocol in Silverlight 3 > requires client affinity to a particular physical server machine for the > lifetime of the WCF channel (WCF proxy). Moreover, the server maintains > in-memory state for the duration of the session with the client. If you > are using a load balancer that cannot guarantee client affinity to a > particular backend, or if your hosting infrastructure cannot guarantee > that the service will keep running on the same machine, the protocol > will fail. In the practice of load balanced web farms, the Silverlight > polling duplex protocol in the current form does not scale out well. > > > Scale out solution to this problem here ... > http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html > > > > And porting that scalable solution to the cloud > http://blogs.msdn.com/ales/archive/2009/09/22/scalable-duplex-messaging-with-silverlight-3-and-windows-azure.aspx > > > > .peter.gfader. > http://peitor.blogspot.com/ > http://twitter.com/peitor > > > > On Tue, Mar 30, 2010 at 5:44 PM, ross [email protected]> wrote: > > Interesting. > > > > Do you know, does "Silverlight 4: Duplex WCF over TCP" have any issues > > with server affinity in a web farm / load balancing configuration? > > > > I believe that might be an issue with Duplex WCF over http. > > > > > On Tue, Mar 30, 2010 at 4:08 PM, Peter Gfader [email protected]> wrote: > > > 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 > > > > > > People on the web should be able to use it > > > No download of an application > > > Broadcasting messages to all user (server to clients) > > > Everyone should be able to use it > > > > > > People behind firewalls, proxies, NATs, … > > > People with 1 of the current browsers > > > > > > 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) > > > 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 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 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. > > >>> > > >>> Sockets > > >>> Polling over WCF in SL2 or SL3 (HTTP) > > >>> WCF net.tcp protocol in Silverlight 4 (Polling over TCP Sockets) > > >>> > > >>> Anyone has some good or bad experience with them? > > >>> > > >>> > > >>> > > >>> Regarding > > >>> > > >>> Performance > > >>> Ease of development > > >>> Security (Firewalls are not a problem) > > >>> > > >>> > > >>> > > >>> My opinion so far: > > >>> > > >>> Sockets > > >>> > > >>> Harder to write than calling a WCF service > > >>> Best option regarding performance > > >>> > > >>> Polling over WCF (HTTP) > > >>> > > >>> Not a nice solution regarding performance > > >>> > > >>> WCF net.tcp protocol in Silverlight 4 (Polling over TCP Sockets) > > >>> > > >>> Under the hood sockets, but I don't have to worry about sockets > > >>> 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 > > > > > > > > _______________________________________________ > > ozsilverlight mailing list > > [email protected] > > http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight > > > > > > > _______________________________________________ ozsilverlight mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
