64K socket send limit

[Brian Ford <Brian dot Ford at FlightSafety dot com>]

I'm concerned that while the following change may be standards compliant,
it may also break a lot of legacy applications that have not been coded
portably enough to handle it gracefully.

2008-03-07  Corinna Vinschen  <corinna at vinschen dot de>

        * fhandler_socket.cc (fhandler_socket::sendto): Never send more than
        64K.  Add comment to explain why.
        (fhandler_socket::sendmsg): Ditto.

I am familiar with the reasoning for this change, and I understand that
portable applications should handle partial sends.  But in practice, they
very rarely if ever happen on *nix.  And when they do, it is usually only
in the case of a signal being caught.

Here is what SUSv3 has to say about it:

If space is not available at the sending socket to hold the message to be
transmitted, and the socket file descriptor does not have O_NONBLOCK set,
send() shall block until space is available. If space is not available at
the sending socket to hold the message to be transmitted, and the socket
file descriptor does have O_NONBLOCK set, send() shall fail.

To avoid a partial send surprise for blocking TCP legacy applications, I
suggest Cygwin use an internal 64K chunk loop to complete the full buffer
send if possible, only returning a shorted value if an error occurs during
the loop iteration.  The current behavior is probably fine, however, for
UDP and non-blocking sends.

I suggest something similar to, but more optimal that the following:

http://support.microsoft.com/kb/227672

Please let me know if I've entirely missed something here as I haven't
done anything more than inspect the code to come to my conclusion.

Comments?

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...