[hunchentoot-devel] COMET with Hunchentoot?

[Hans Hübner]

On Thu, Feb 26, 2009 at 22:01, Jim Prewett <download at 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