On Wed, 30 Mar 2005, Brian Ford wrote:
On Tue, 29 Mar 2005, Peter A. Castro wrote:
On Tue, 29 Mar 2005, Brian Ford wrote:
If you are doing a normal blocking recv without MSG_PEEK, any return of 0
should mean a closed connection AFAIK.
Unfortunately that's not true for all implementation. It's legal for a
zero length data object to be sent. The network simply sends a header
with no payload in it, but it's passed through the network anyways and is
presented to the receiver. The receiver, which might be blocking at the
time, will return from the call and get zero length data, but the
connection is still valid at this point. I've seen AS/400's do just this
sending zero length data to an AIX box. If the sender closes the
connection normally, then subsequent calls to recv return zero with no
indication that the connection is closed. Call it a bug if you want, but
that's how it works.
I agree that zero length data can be sent, but only for UDP or datagram
based sockets, not for TCP or stream based ones (nothing denotes a message
here). Even then, they are only sent by application choice, not just
randomly by the OS. Whether a connection is open or closed in this case
has little meaning.
Nope, sorry, the example I cited above was using TCP, and wasn't really
the applications choice (as I wrote both the server and client apps on
both ends in this example, I can tell you the server app did not send
zero byte data, but the client got a zero byte return after a previous
non-zero byte return). The network stack on the AS/400 is rather awful
and does send empty segments at odd times. It's a real life example.
Unfortunately it's neither Cygwin nor Linux, and so likely not relevent
for the OP.
--
Brian Ford
--
Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
"Cats are just autistic Dogs" -- Dr. Tony Attwood
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
