David Delbecq schrieb:
Here a diagram:
Client sends GET -> Server
Server sends HEADERS (Content Encoding: Chunked) -> Client
Server sends chunks -> Client
Client displays them whenever they arrive.
Just one point. If your 'client' is a classical browser it won't work
like this out of the box, for the simple reason you have no guarantee
the client will do any display before it receive </html>
There are provisition in http standard for a progressive display of a
page. I can't remember like that the references in http 1.1 specs, just
give it a look. It's based on a server pushing of page refreshes on a
keep-alive connection. But it need special headers.
Well in practice and real life it works fine. All the major Browser
display the content, which they receive right away, as long as it's a
complete chunk or message.
I think its better anyway not to wait for the whole message to complete
before displaying it. Why let the user wait, if you can already display
part of the content?!
I could just remember the HttpRespone Objects and use one thread,
which gets, when new messages arrive in the queue. The thread then
could println() them to all he HttpRespones. This would save me all
the Threads. Hmm, sounds good, or have I missed somthing?!
Yes, one thing, when doGet() returns, the container *could* close the
connection. (This is tomcat internal dependent and should not be
assumed as deterministic).
As a side note, as stated by other people already, you should probably
write your own standalone application if you intend to keep all
connections alive for your chat.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
