Hello,
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.
Thanks, Jim
James E. Prewett Jim@Prewett.org download@hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210
I have a working comet system using Hunchentoot.
The basic way I'm operating is to have the browser contact the hunchentoot server and the server thread waits on a semaphore. Any other thread can then release the semaphore and cause a reply back to the browser.
Hope this helps. I am only using this for development purposes, as I have been having problems with certain browsers, and this will also occupy one of the available browser requests, where many browsers have a very small number available.
(defun kill-comet-thread (thread) (warn "KILLING COMET THREAD: ~a" thread) (ignore-errors (destroy-thread thread)))
(defun handle-comet () (awhen (session-value 'comet-thread) (kill-comet-thread it)) (setf (session-value 'comet-thread) *current-thread*) (wait-on-semaphore (session-value 'comet-semaphore)) (setf (session-value 'comet-thread) nil) (aif (session-value 'comet-fn) (funcall it)))
(defun comet (fn &optional (session *working-session*)) (setf (session-value 'comet-fn session) fn) (signal-semaphore (session-value 'comet-semaphore session)))
On Thu, Feb 26, 2009 at 4:01 PM, Jim Prewett download@hpc.unm.edu wrote:
Hello,
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.
Thanks, Jim
James E. Prewett Jim@Prewett.org download@hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/http://www.hpc.unm.edu/%7Edownload/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
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
On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner hans.huebner@gmail.com wrote:
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".
...
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.
Don't you think that having separate thread handling comet would be simpler? I/O multiplexing to the clients with some sort of message queueing API for requests from the app engine would be sufficient to make it work? The only obstacle for multiplexed I/O is lack of portable non-blocking I/O library.
/S
On Fri, Feb 27, 2009 at 16:42, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner hans.huebner@gmail.com wrote:
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".
...
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.
Don't you think that having separate thread handling comet would be simpler? I/O multiplexing to the clients with some sort of message queueing API for requests from the app engine would be sufficient to make it work? The only obstacle for multiplexed I/O is lack of portable non-blocking I/O library.
Yes, a specialized COMET handling system would be possible. It may make sense to use a specialized task master so that connections which are waiting on a server-side event do not tie up a worker thread. The new taskmaster/acceptor architecture is meant to support that.
usocket has recently seen quite some changes to support non-blocking communications, although I think that this work is not yet finished. Working on that would propably be easier than replacing Hunchentoot's networking layer.
Nothing of this is on my current task list, sadly.
-Hans
On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner hans.huebner@gmail.com wrote:
On Fri, Feb 27, 2009 at 16:42, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner hans.huebner@gmail.com
wrote:
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".
...
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.
Don't you think that having separate thread handling comet would be
simpler?
I/O multiplexing to the clients with some sort of message queueing API
for
requests from the app engine would be sufficient to make it work? The
only
obstacle for multiplexed I/O is lack of portable non-blocking I/O
library.
Yes, a specialized COMET handling system would be possible. It may make sense to use a specialized task master so that connections which are waiting on a server-side event do not tie up a worker thread. The new taskmaster/acceptor architecture is meant to support that.
I see a bit of a problem with that API for this purpose. One would want to somehow distinguish between comet and non-commet calls. To do this you would have to inspect URI or method of the request to spawn a thread or pass the request to dedicated comet handler for example. Handle-incomming-connection is used to customize task creation. It uses process-connection to do the work which in turn calls get-request-data to get URI, method and headers. It's after taskmaster dispatch. It would be nice to be able to handle static content by single thread and dynamic content with one request per thread. Or even proxy the static content via external server. I don't know of any HTTP server able to do this :) Simplest method of implementing it would exposing process-connection API and adding optional argument, say request-info, which would be preloaded with info returned by get-request-data retrieved earlier to decide how to handle the request. Now you would have to rewrite process-connection altogether to get the same effect.
usocket has recently seen quite some changes to support non-blocking
communications, although I think that this work is not yet finished. Working on that would propably be easier than replacing Hunchentoot's networking layer.
Agreed. You must have some insider info on this ;) The only trace of non-blocking socket I/O in usocket that I could find was in two .txt files distributed with usocket 0.4.1
Regards, /S
On Sat, Feb 28, 2009 at 14:01, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner hans.huebner@gmail.com wrote:
Yes, a specialized COMET handling system would be possible. It may make sense to use a specialized task master so that connections which are waiting on a server-side event do not tie up a worker thread. The new taskmaster/acceptor architecture is meant to support that.
I see a bit of a problem with that API for this purpose. One would want to somehow distinguish between comet and non-commet calls. To do this you would have to inspect URI or method of the request to spawn a thread or pass the request to dedicated comet handler for example.
Wouldn't you be able to write a task manager that first reads the request header, then decides whether the request is a COMET request and queue it or hand it over to another thread for processing? You might still want to have multiple connection handling threads in order to have some concurrency in request header reading, but such a scheme should be possible with the current architecture. Or am I missing something?
-Hans
On Mon, Mar 2, 2009 at 11:49 AM, Hans Hübner hans.huebner@gmail.com wrote:
Wouldn't you be able to write a task manager that first reads the request header, then decides whether the request is a COMET request and queue it or hand it over to another thread for processing?
If you first read the request header, you're interfering with the rest of the architecture which expects to be able to read the whole request including headers from the client.
Edi.
On Mon, Mar 2, 2009 at 12:49, Edi Weitz edi@agharta.de wrote:
On Mon, Mar 2, 2009 at 11:49 AM, Hans Hübner hans.huebner@gmail.com wrote:
Wouldn't you be able to write a task manager that first reads the request header, then decides whether the request is a COMET request and queue it or hand it over to another thread for processing?
If you first read the request header, you're interfering with the rest of the architecture which expects to be able to read the whole request including headers from the client.
The interaction between PROCESS-CONNECTION and PROCESS-REQUEST would need to be revised in a manner that makes it possible for a request handler to return to in a manner that prevents the stream from being closed or polled for data again. As a start, reading the request header, creating the request object instance, processing the request and sending back the reply should be split and made more explicit so that an application could implement a different flow of control, but still use the components that Hunchentoot uses.
The COMET acceptor class would then be able to interrogate after the headers of the request have been read and handle COMET requests differently from others.
-Hans
On Mon, Mar 2, 2009 at 12:49 PM, Edi Weitz edi@agharta.de wrote:
On Mon, Mar 2, 2009 at 11:49 AM, Hans Hübner hans.huebner@gmail.com wrote:
Wouldn't you be able to write a task manager that first reads the request header, then decides whether the request is a COMET request and queue it or hand it over to another thread for processing?
If you first read the request header, you're interfering with the rest of the architecture which expects to be able to read the whole request including headers from the client.
You are obviously right. My suggestion was splitting the request retrieval from it's processing (as done by process-connection) to be able to make an informed decission about further processing. Process-connection or any other API devised for this purpose would have to somehow accept request data read up the stack.
/S
On Mon, Mar 2, 2009 at 11:49 AM, Hans Hübner hans.huebner@gmail.com wrote:
On Sat, Feb 28, 2009 at 14:01, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner hans.huebner@gmail.com
wrote:
Yes, a specialized COMET handling system would be possible. It may make sense to use a specialized task master so that connections which are waiting on a server-side event do not tie up a worker thread. The new taskmaster/acceptor architecture is meant to support that.
I see a bit of a problem with that API for this purpose. One would want
to
somehow distinguish between comet and non-commet calls. To do this you
would
have to inspect URI or method of the request to spawn a thread or pass
the
request to dedicated comet handler for example.
Wouldn't you be able to write a task manager that first reads the request header, then decides whether the request is a COMET request and queue it or hand it over to another thread for processing? You might still want to have multiple connection handling threads in order to have some concurrency in request header reading, but such a scheme should be possible with the current architecture. Or am I missing something?
It is possible, but handle-incomming-connection is now in fact a thin wrapper around process-connection which does all the work, thus having process management depend on request contents requires one to patch or rewrite process-connection to simply avoid reading request data which have been read already. /S
On Mon, Mar 2, 2009 at 18:04, Slawek Zak slawek.zak@gmail.com wrote:
It is possible, but handle-incomming-connection is now in fact a thin wrapper around process-connection which does all the work, thus having process management depend on request contents requires one to patch or rewrite process-connection to simply avoid reading request data which have been read already.
I did not mean to say that it would be possible without changing Hunchentoot. In fact, I meant to say that the interaction between PROCESS-CONNECTION and PROCESS-REQUEST would need to be rewritten. I have no current plans to do this, as I don't need the feature. If you plan on doing it, looking at http://weitz.de/patches.html and discussing the details of the proposed API here will increase the likeliness that it will end up in Hunchentoot itself.
-Hans
On Mon, Mar 2, 2009 at 7:01 PM, Hans Hübner hans.huebner@gmail.com wrote:
On Mon, Mar 2, 2009 at 18:04, Slawek Zak slawek.zak@gmail.com wrote:
It is possible, but handle-incomming-connection is now in fact a thin wrapper around process-connection which does all the work, thus having process management depend on request contents requires one to patch or rewrite process-connection to simply avoid reading request data which
have
been read already.
I did not mean to say that it would be possible without changing Hunchentoot. In fact, I meant to say that the interaction between PROCESS-CONNECTION and PROCESS-REQUEST would need to be rewritten. I have no current plans to do this, as I don't need the feature. If you plan on doing it, looking at http://weitz.de/patches.html and discussing the details of the proposed API here will increase the likeliness that it will end up in Hunchentoot itself.
Fine, I will try to come up with some clean API and implementation to do this.
/S
There is NIO library (http://common-lisp.net/project/nio/), but it seems forsaken...
On Fri, Feb 27, 2009 at 5:42 PM, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner hans.huebner@gmail.comwrote:
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".
...
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.
Don't you think that having separate thread handling comet would be simpler? I/O multiplexing to the clients with some sort of message queueing API for requests from the app engine would be sufficient to make it work? The only obstacle for multiplexed I/O is lack of portable non-blocking I/O library.
/S
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
By the way, there's also SymbolicWeb ( http://en.wikipedia.org/wiki/SymbolicWeb), which advertises to be doing Comet and using Hunchentoot. But somehow its pages on Google(Groups and Code) have gone recently...
On Thu, Feb 26, 2009 at 11:01 PM, Jim Prewett download@hpc.unm.edu wrote:
Hello,
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.
Thanks, Jim
James E. Prewett Jim@Prewett.org download@hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/http://www.hpc.unm.edu/%7Edownload/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
This project has been abandoned by this author, which is unfortunate. In it's late stages it started using new fully asynchronous HTTP server (sw-http) written just for the purpose of speeding up comet. It was before Hunchentoot's taskmanager API.
/S
On Fri, Feb 27, 2009 at 5:32 PM, Vsevolod vseloved@gmail.com wrote:
By the way, there's also SymbolicWeb ( http://en.wikipedia.org/wiki/SymbolicWeb), which advertises to be doing Comet and using Hunchentoot. But somehow its pages on Google(Groups and Code) have gone recently...
On Thu, Feb 26, 2009 at 11:01 PM, Jim Prewett download@hpc.unm.eduwrote:
Hello,
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.
Thanks, Jim
James E. Prewett Jim@Prewett.org download@hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/http://www.hpc.unm.edu/%7Edownload/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- vsevolod
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
The SymbolicWeb project has been canned according to its author, Lars Nostdal. :P
Jim
James E. Prewett Jim@Prewett.org download@hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210
On Fri, 27 Feb 2009, Vsevolod wrote:
By the way, there's also SymbolicWeb ( http://en.wikipedia.org/wiki/SymbolicWeb), which advertises to be doing Comet and using Hunchentoot. But somehow its pages on Google(Groups and Code) have gone recently...
On Thu, Feb 26, 2009 at 11:01 PM, Jim Prewett download@hpc.unm.edu wrote:
Hello,
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.
Thanks, Jim
James E. Prewett Jim@Prewett.org download@hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/http://www.hpc.unm.edu/%7Edownload/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- vsevolod
-
Edi Weitz -
Hans Hübner -
Jim Prewett -
Slawek Zak -
Vsevolod -
William Halliburton