Pushing messages to clients from a server-side application?

Question

I have a javascript-based client that is currently polling a .NET web service for new content. While polling works...I'm not happy with this approach because I'm using system resources and creating overhead when there aren't any changes to receive.

My question is how do I notify my client(s) that there is new content for it to display? I am open to on any additional technologies I would have to implement this solution with.

Mcleroy

Answer 1

First of all, polling is the way to go. You could do it with Flash or Silverlight or Comet - http://en.wikipedia.org/wiki/Comet_(programming) which can hold a tcp connection open for you for notifications. A webpage itself cannot hold a socket open, so there is no way to directly notify a web client.

[Edit] But think about it, how many client can hold a tcp connection towards one server at a time? For a larger system you would run out of available sockets pretty fast as there are 65k ports available.
How many concurrent connections your server can handle depends on your hardware resources. If you have enough memory and cpu you should be able to handle ~100k and maybe more. But if each request access a database or some other resource over tcp/ip, you could be limited to the number of ports per ip available (65k). You should also have the push requests go against a separate domain, as a browser normally caps to two concurrent connections per domain, so you won't interfere with the normal page loading.

Using polling in combination with cache servers in the front is a good solution. You can have logic on the server which updates the cache per client, reducing the load for each poll. You could update the cache for users who have signed in/polled within the X number of minutes to reduce the cache updating even more. And to me implementing pull is easier than pull, technology wise.

Winton

Yes, it can be done without Flash and Silverlight; see the answers about en.wikipedia.org/wiki/Comet_%28programming%29 – Traps

Great answer, this gave me some good places to start looking. – Mcleroy

Hi, can I check the comment about running out of ports or sockets - is this something to do with .NET (which I am not familiar with)? A regular COMET solution would not use multiple ports on the server, I think, assuming all the clients are using the same server address, although it will use multiple threads (and/or whatever your server uses to serve each 'connection') which is why large applications typically need the servers designed or enhanced to support COMET - i.e. to handle a large number of long lived connections doing very little as they are in a suspended state. – Cuttler

@Mick: The max number of ports in tcp/ip is 2^16. It's related to the protocol, not .Net or the OS. When a client starts a request, a data port is opened back to the client, usually in the range 1024-65535. Each client holding a port open (idle or not) will consume from that range. If 65k clients hold a connection at the same time, then the next client connection will not get a response back, as there are no more ports avaiable for data transfer. This is why polling works better, as the client (at least in theory) will close the connection after each request, making ports reusable. – Winton

I don't believe this is true. Clients connect to a specific port on the server and the number of simultaneous connections on that port is limited only by the server's internal memory and OS settings. – Agglutinative

Peter is right, the port is just the channel a specific type of communication is taking place on. The server has to be designed to listen to multiple requests on that port. Port 80 is designated for web server requests, but the server handles many requests on that one port. – Mcleroy

@Peter: I stand corrected, and you are of course absolutely right on this when it comes to http traffic. I have revised my answer to reflect this. – Winton

Thanks for the correction - I think there is still an issue with the line: "you could be limited to the number of ports per ip available (65k)". Again, in normal circumstances all the COMET messaging (no matter how many connections) will use the same port so the limit is really with the server hardware and architecture. This is again where a server that has been designed or modified to handle large numbers of COMET connections is an advantage. – Cuttler

@Mick: The sentence with 65k ports relates to if your request kicks off other requests using tcp/ip ports. If 100.000 web users each kick off an LDAP query, you will run out of ports for the LDAP calls internally on the server. – Winton

Again, I think the database requests will all be on whatever port the database is connected on, so it will not exhaust 'ports per IP'. You may exhaust some other database connection resource so it is certainly worth considering. – Cuttler

@Mick: If you don't look at connection pooling, then each outbound request to an SQL server will have it's own outgoing socket, even though they connect to the same port on the SQL server. 10 simultanious connections needs 10 outbound sockets. Agree? – Winton

Hi. Simultaneous connections will definitely use up resources on the server so I think this is very valid to highlight, just not IP Ports. – Cuttler

Here's some netstat lines from my machine: TCP-10.0.0.4:52892-69.59.196.216:80 (one local port on my machine allocated when connecting to a webpage). TCP-10.0.0.4:52892-10.0.0.5:1433 (one local port on my machine allocated when connecting to an sql server). You have to think about the server as the client when it executes calls to other systems, originated by some web request. One call into my webserver could very well kick off those two calls which I list in the beginning, consuming two ports. – Winton

Answer 2

You should research about COMET.

COMET is a Technique that enable a server to push data to client browsers through an HTTP open line of communication.

Probably there are examples overthere about COMET + WCF Web services.

Jobi

Answer 3

Check out WebSync, a comet solution for .NET/IIS. It'll do exactly what you're looking for. No extra polling wasting resources, push only when needed, real-time updates...the whole 9 yards.

Fonzie

Answer 4

http://www.ape-project.org/ is I think a good place for you to look. Its based on ajax push or as some call it reverse ajax. There are other projects as well and it is based on: http://en.wikipedia.org/wiki/Comet_(programming)

I mentioned ape project because you can use JavaScript with it or if you want C++, PHP, Python, etc on the server side. :-)

Rolling

Answer 5

You've been already told about HTTP polling (COMET). This leaves open the question how does the http server itself (IIS+ASP) detect the changes in the database without polling the database. With SQL Server you can use a technology like Query Notifications, which allows your ASP.Net process to be notified when a change occurs in the database on a record it has cached. You can also check out the LinqToCache project that allows Query Notification to be mixed with LINQ queries.

Unusual