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 * restart the timeout clock from each successful packet transmission Bill
