Server Push For Applets?

John asks: "I'm designing a system where 10,000 applet based clients can view prices for a bunch of products. A requirement is that when a price changes, the clients see the new price within a few seconds. Basically, I'd like to push content to them. But a lot of them are behind firewalls, so a socket-based solution won't always work. OTOH, if they poll the server every couple of seconds using HTTP, that's 5,000 requests per second, which will require a server farm and multiple T1 lines. Does anyone know a more elegant way? I considered using HTTP requests that block in the server until a response is ready, but then I need to support 10,000 blocked threads and concurrent connections - another server farm. There's got to be a better way..."

Comments

Threads and concurrent connections

[Alex Belits]

There is no way to avoid keeping idle connections open if the data can arrive at any moment. However with proper design (that means, not Apache -- callback-based model won't work well there) you don't have to waste any resources on them except a file descriptor and small amount of memory for some internal structures. Having large number of mostly-idle tcp connections is not something unheard of -- any large IRC server does that for thousands of idle users -- however the design of most HTTP servers is not optimized for this.

One of the goals of my fhttpd server design was to separate the model of request processing in the backend from internals of HTTP server itself, and the examples in my previous messages are running on custom backends written for fhttpd -- webcams are always six processes without any additional threads (three processes per camera -- one process talks to http server, one talks to the camera, one compresses jpegs -- the program is released as qcwebcam), and X-10 is handled by a single process (also with no threads involved) that handles everything and talks to X-10 "modem" through a serial port.