Pushing messages to clients from a server-side application?

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.

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

Marcel Korpel 2010-08-04 18:53:58

@Marcel: thanks.. edited my answer to reflect that.

Mikael Svenson 2010-08-04 18:56:27

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

Achilles 2010-08-04 19:31:09

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.

Mick 2010-08-05 17:19:16

@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.

Mikael Svenson 2010-08-06 10:09:17

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.

Peter Ruderman 2010-08-06 18:08:59

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.

Achilles 2010-08-06 18:23:12

@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.

Mikael Svenson 2010-08-06 20:13:38

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.

Mick 2010-08-09 10:11:03

@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.

Mikael Svenson 2010-08-09 12:23:01

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.

Mick 2010-08-13 12:40:00

@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?

Mikael Svenson 2010-08-13 15:17:35

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

Mick 2010-08-14 09:00:10

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.

Mikael Svenson 2010-08-14 12:56:16

ansaurus

tags:

views:

answers:

Pushing messages to clients from a server-side application?

related questions