tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11:
Date Fri, 16 Jun 2006 23:22:41 GMT
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 Hanik

View raw message