views:

184

answers:

2

Hi. I currently need to make the silverlight 4 in-browser app that can receive push messages from the server. I presume using sockets is the best way, and will also allow a connection between server and client to transfer data and update the page. But I am worried about firewalls and/or proxy servers. Is it possible to have push technology, or even sockets at all, whilst behind a proxy that may block everything that isnt on port 80? Or is it possible to have socket connections on port 80 which would be perfect because it would bypass both proxy and firewall. I am aware that there is a set range of ports available for silverlight, so im meaning a work around.

While on the subject...Would sending a mass block of data from silverlight be faster through sockets, ASP.NET AJAX, or connection to an ASMX web service?

Thanks a ton!

A: 

You can't connect to TCP socket with port 80 in Silverlight. As you've state there is a limited range of ports (4502-4534) you can connect to and thats it.

Yes firewall will be a concern, just as with other applications such as RDP remote access the firewalls involved between the client and server need to allow connection through one of the allowed port numbers.

Speed of data transfer is largely a function of its encoding. (I don't think AJAX is in the picture here). Ultimately sockets with binary encoding tend to be a bit quicker especially for frequent small transmissions. Whereas HTTP suffers with a bit more overhead however you are much less likely to have a problem with a firewall.

Unless you have a really, really good reason to use sockets use a HTTP based protocol instead. If you abstract out this part of your app reasonably well you could always swap it later.

Have you considered using a WCF PollingDuplex Channel? This allows you to create the "push" from server mechanism whilst sticking with HTTP. In addition much of the plumbing is done for you.

AnthonyWJones
Thanks, I will take a look at WCF PollingDuplex. Before I do though, this article: http://dotnetaddict.dotnetdevelopersjournal.com/sl_polling_duplex.htm says its not scalable. This will be used by a high number of people, so unnecessary overhead isnt an option. If this is true, is there a better HTTP based option?Thanks.
Matt
@Matt: Define a "high number of people"?
AnthonyWJones
A few thousand.
Matt
@Matt: right then the next question is how much lag can be tolerated between a message being generated and it arriving on the client? Also how frequently would a single client get a messages?
AnthonyWJones
Well, the frequency will range drastically, but could be once per second at shortest. And a second or two would be an acceptable wait time - which is why im looking at push.Ive been looking at WCF and polling duplex, and as far as I understand, using polling duplex is the same as plain WCF except that a channel is left open so for frequent requests(polling) there is no overhead. Is this right?
Matt
A: 

Here's a great article on WCF Polling Duplex (HTTP Long polling or COMET Style) hopes this helps. It's a bit out dated by the content will get you started.

http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html

JeremySpouken