Return-Path: 
 <users-return-143544-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 82017 invoked from network); 3 Apr 2006 14:01:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 3 Apr 2006 14:01:51 -0000
Received: (qmail 31961 invoked by uid 500); 3 Apr 2006 14:01:40 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 31555 invoked by uid 500); 3 Apr 2006 14:01:39 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 31544 invoked by uid 99); 3 Apr 2006 14:01:39 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 07:01:39 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [213.239.213.83] (HELO www.drive2day.de) (213.239.213.83)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 07:01:38 -0700
Received: from localhost (localhost [127.0.0.1])
	by www.drive2day.de (Postfix) with ESMTP id 2423A734036
	for <users@tomcat.apache.org>; Mon,  3 Apr 2006 15:44:29 +0200 (CEST)
Received: from www.drive2day.de ([127.0.0.1])
	by localhost (www.drive2day.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 08746-07 for <users@tomcat.apache.org>;
	Mon, 3 Apr 2006 15:44:28 +0200 (CEST)
Received: from [192.168.1.2] (debian [213.239.213.83])
	by www.drive2day.de (Postfix) with ESMTP id 3A555734033
	for <users@tomcat.apache.org>; Mon,  3 Apr 2006 15:44:28 +0200 (CEST)
Message-ID: <44312A51.2080404@weboperations.com>
Date: Mon, 03 Apr 2006 16:59:45 +0300
From: Tp <tp@weboperations.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Rephrased: Maximum number of simultaneous HTTP connections
References: <4430F86B.2080503@weboperations.com>
 <44314702.60501@gmail.com>	 <6d959d480604030403w3ecf9720xd7fb469ff1d8d11c@mail.gmail.com>
	 <443104D6.9070206@weboperations.com>
 <6d959d480604030441o6597f85cn556dfb6ab1bea086@mail.gmail.com>
 <44311B5D.2090503@weboperations.com> <4431242B.4010200@oma.be>
In-Reply-To: <4431242B.4010200@oma.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at drive2day.de
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org