Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3EA92825.1090407@wstoddard.com>
Date: Fri, 25 Apr 2003 08:20:53 -0400
From: Bill Stoddard <bill@wstoddard.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
CC: dev@apr.apache.org
Subject: Re: Win32 apr_sockets; Random notes from the 'oh, duh'   department
References: <5.2.0.9.2.20030423191039.04457390@pop3.rowe-clan.net>
 <5.2.0.9.2.20030423144809.02b15e18@pop3.rowe-clan.net>
 <5.2.0.9.2.20030423144809.02b15e18@pop3.rowe-clan.net>
 <5.2.0.9.2.20030423191039.04457390@pop3.rowe-clan.net>
 <5.2.0.9.2.20030424140712.022e2cd0@pop3.rowe-clan.net>
In-Reply-To: <5.2.0.9.2.20030424140712.022e2cd0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> At 01:15 PM 4/24/2003, Bill Stoddard wrote:
> 
> 
>>>>That should not be the case. Last time I checked, I though we set the timeout then sent 64K (?) chunks then reset the timeout for the next 64k chunk. This is -eaxactly- what 1.3 does on Unix (where signals are used as the timeout mechanism). This has someone changed that w/o my noticing? I'll check later...
>>>
>>>No, especially not in the case of mmaps.  The way filters, brigades and
>>>buckets work, you can end up with a 16MB sendfile or 4MB mmap.  In
>>>the later case, you may have 4MB * 16 iovecs in a single WSASend.
>>
>>Humm... I am wondering if breaking up sends should really be the responsibility of APR. Consider that the application sets the send timeout, the application understands how its expected to behave and what kind of link it is talking over. Seems it should be able to control the size of the buffer to send and the time it will allow for it to be sent.  Using that line of reasoning, one could argue that if the app (httpd in this case) sent to APR a 4MB mmap to send but did not set an appropriate timeout, that it is httpd that is at fault if the send does not complete before the timeout fires.
> 
> 
> I partially agree that *apr* networking shouldn't worry about this.  Clearly,
> *apr-util* brigades and buckets need to consider this impact.  But I am
> confused by one thing...
> 
> When I implement timeout mechanisms, they are always 'inactivity' timers.  
> E.g., I presumed that SO_SNDTIMEO/SO_RCVTIMEO were timing out 
> based on the intra-transmission delay, not on the total time of the operation.
> Stevens didn't help on this - so I'm hoping someone can share if those
> options either;
> 
>  * timeout clocked from the start of the entire transmission, or
Yep, pretty sure this is what it means. You do a WSASend for 100,000 
bytes and you have SO_SNDTIMEO for the stack to take ownership of your 
buffers to complete the send.

Bill