Persistent HTTP Requests in BSP: Can you Flush the Response without Ending It?

Question

Hello all,
I have been looking for a way to implement a persistent HTTP Request in a BSP.  This means the server keeps the request open as long as possible and sends data periodically to the browser without closing the request.  In other development environments, there would be a way to flush the response to the client, separate from closing the connection, thus making this possible.  I have looked and do not see any way to do this.
Also, if it is not possible with a BSP, is there another way to do this via the Web Application Server?
Thanks for any help,
-Chris

Answer 1

There are various limits: the number of sockets / file descriptors that the operating system lets a program have open, the amount of socket buffer space in the operating system, the number of simultaneous connections that the web server allows. Each of these can be configured.
One problem is that a web server starts a thread for each hit. If you have 1000 simultaneous active hits you have 1000 threads. That is quite a lot. I've seen server OSes start buckling at around 400-500 threads. Given a suitable OS you may get higher with a bit of configuration, but I'd say the number of threads is rather a big concern. 100,000 threads? That dog don't hunt.
An alternative would be not to use a regular web server, but to use a NIO select -based server. Then you can have one thread that handles all the connections. I once did that to write a stock ticker applet. But if you want to do fully standards compliant HTTP implementation that's not trivial.
If you are writing the client applet as well as the server, consider using a simpler protocol than HTTP and writing a NIO server. NIO isn't quite trivial to get really right; look at examples and tutorials; google is your friend. If you can keep each client's connection open do so; establishing and tearing down hundreds or thousands of connections a second, and sending HTTP request and reply headers, is going to eat network and CPU resources.
If you are really targeting 100,000 clients at 5 seconds between messages, that comes to 20,000 messages per second. That's a lot; plan for a load balanced server cluster.