Out of band data (was issues prior to 1.0?)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 10:01 AM 6/25/2003, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>>
>>Let me add 
>>* no support of out-of-band network data whatsoever.  That really concerns
>> me and I will probably address it over the next two weeks.
>
>Elaborate please.

send() takes a fourth argument, such as OOB.  Our apr_send() has no such
support for out of band data.  On recv, there are a couple of ways of recovering
out of band data, and we should support one or more models.

Once APR can handle it, it's trivial to finish the minimal telnet protocol filter
I'm working on.  If we see an out-of-band IP/Sync sequence, I can drop that
into a custom metadata bucket, and conventional (read: fast) server applications
can simply drop them on the floor.  The entire OOB construct doesn't really
fit into server apps running on 1GHz CPU, but they still must be acknowledged
in order to implement minimal-telnet, which is a requirement for SMTP, FTP
and a number of other telnet control-channel based protocols.

>* real problems with files opened for sendfile, which no longer block correctly
>> on win32, e.g. our entire logic may be invalid.  Try filtering any buckets
>> prepared for sendfile on win32 with the XTHREAD logic to see the issue.
>Sounds like a Windows bug to me but certainly worth investigating more. I would be very against moving away from the use of the SENDTIMEO/RCVTIMEO model on Windows unless it is definitively proven that Windows is broken and that MS has no intent to fix the brokeness.

I agree - no doubt it's a Win32 bug.  My observation is that when you take
a 5MB file, destined to be 'sendfile'd (so it's open with XTHREAD - overlapped
I/O model), and mmap it in order to filter it, the apr_sendv() call will return
immediately as if the data is sent.  We do nothing therein around overlapped
I/O, in fact the overlapped arg is NULL.  So the simple bug appears to be that
any file opened for sendfile cannot be mmaped and WSASend()'t.

After the discovery, I've been too buried in small transfer mechanics to
revisit this huge transfer bug.  But I'm guessing this is behind some of
the complaints from PHP and other forums that the "bug in XP afd.sys" 
appears to affect more users than those that should be affected.

Bill