On Thu, Feb 26, 2009 at 22:01, Jim Prewett download@hpc.unm.edu wrote:
I'm not quite sure what I'm after except that the buzzword seems to be "COMET".
AFAICT, much of the time, this involves having javascript send an XMLHttpRequest to the server which the server keeps open until there is data to be sent to the client.
Has anyone done anything like this? Does anyone have thoughts on how one might implement something along these lines?
All I am really after is some sort of "Server Push" - I'd be happy to hear any thoughts anyone has along these lines.
As William has posted as a followup, such a scheme is straightforward to implement with Hunchentoot when you are using the standard multi-threaded mode. In that mode, every new incoming connection is handled by a separate thread, so there is nothing wrong with keeping the handler function waiting for an even, and then return to the client.
The issue with that approach is lack of scalability. It will only work well for a restricted number of threads, and you cannot expect it to work with hundreds or thousands of simultaneous connections. I cannot come up with any hard facts or numbers, but I have never seen anyone claim that his Hunchentoot based server works well with more than a few dozen simultaneous connections. Possible issues are the experimental nature of the threads implementation in a popular open source CL implementation, the memory footprint of the threads created, and the difficulty to create bug free multi-threaded programs in general.
Successful and reliable COMET style servers are usually implemented using I/O multiplexing: There is only one thread which uses an optimized multiplexing system call to determine which of a number of channels (e.g. sockets) has data waiting to be received or space in its buffer so that the application can send some data. The server application is written in a non-blocking, event oriented style. All blocking operations in such a system are coordinated by the centralized event scheduling mechanism instead of relying on thread synchronization primitives.
Hunchentoot, in its current form, does not support I/O multiplexing in that form. With our recent release, we have tried to restructure things so that adding such a mechanism would be easier than it was, but as we do not have the immediate need or funding to fully implement that, we've not completed it.
The cleanest way to implement a high performance I/O multiplexing framework that could be used by Hunchentoot would be by implementing multiplexed socket streams using coroutines. Obviously, that would require a coroutine library, and I am not aware of such a thing.
Other I/O multiplexing frameworks (i.e. ACE, Twisted, xSocket, iolib) come with their own, specialized HTTP servers which are aware of non-blocking I/O. The reason for this is that event oriented programs need to be structured differently than those which assume a linear flow of control, like Hunchentoot.
All this is only relevant if you are planning to server more than a few users. For prototypes, demonstrations and small-scale applications, using threads as kind of an I/O multiplexing mechanism often works.
-Hans