On Tue, 29 Mar 2005, Brian Ford wrote:
On Mon, 28 Mar 2005, Peter A. Castro wrote:
As someone who's seen this behaviour on several platforms, it can happen. I've had to deal with this little annoyance in other products by having a retry counter loop. So many consecutive recv()s of 0 length constitues a closed connection. Something like this might work here as well?
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.
-- 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/
