Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
what part, the check in or the feature set?
The commit.
the check in, fixes data transfer by doing comet style, ie, both
client and server can "push" data, and working around the HTTP
request/response pull model.
most containers only implement "server async push" but not the client
ability to do the same.
did you have something else in mind?
Yes, getting the read event from the poller means the servlet can do
one blocking read on the socket without blocking. Calling read on the
input stream (if the buffer was empty) will do a blocking read on the
socket. Note that the content delimitation must still be right (maybe
that's why want to reset the remaining bytes) since using Comet isn't
an excuse to break the HTTP protocol: you basically have to use
chunking on input (or use a big content-length - that's what I did in
my testing, it's a cheap trick).
I hear you loud and clear, I've addressed the bug in my previous email.
In terms of breaking HTTP, the comet model already does this, as it
would block the client from sending data until the server decides it is
done sending data to the client, which it can do more than once.
I've attached the model that I am suggesting for Tomcat, as you can see,
the only difference between the one I am suggesting and the comet model,
is that the client also is enabled to send data more than once.
Take a look at the pic and let me know what you think, I'll send it in a
separate email too, so we can get some more eyes on it.
Filip
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
