Re: TCP/IP Sockets -- MIDRANGE-L

Bob,

Yes, when I read the manual a few months ago I drew the same conclusion
you did. And in fact I didn't have any trouble with this for a long
time. Until one fine day when a client application on a UNIX box hauled
off and disconnected itself periodically and my code didn't catch the
error.  I was looking for -1 to trap these kinds of errors. It didn't.
The return code was 0. Here's what the V4R1 manual says in the section
on read():

1.  For sockets that use a connection-oriented transport service (for
example, sockets with a type of 
    SOCK_STREAM), a returned value of zero indicates one of the
following:
 
       The partner program has issued a close() for the socket.
       The partner program has issued a shutdown() to disable writing
to the socket.
       The connection is broken and the error was returned on a
previously issued socket function.
       A shutdown() to disable reading was previously done on the
socket.

I've been bitten by this one. Even curiouser, if you have a non-blocking
read and there is no data to be read you will get a -1 return with errno
equal to EWOULDBLOCK. That is, there really is no error on the socket,
there's just no data to be read. Go figure... 

Patrick

Bob Crothers wrote:
> 
> Patrick,
> 
> I would agree that a zero return on read() is probably an error
> condition as why would the other side send "nothing"?.
> 
> But, the code:
>     int rc = read(mySocket);
> 
>     if (rc == 0)
>         DoErrorCondition();
> 
> Will cause problems as -1 is also returned on blocking calls (what I
> use) when the client disconnects.
> 
> The manual clearly states that -1 is what you must look for.  Instead,
> I would recommend the following:
> 
>     int rc = read(mySocket);
> 
>     if (rc <= 0)
>         DoErrorCondition();
> 
> This way, if you get the 0 returned, it will trigger the error.  If you
> get the -1 as the documentation (and my experience) says you will, you
> will still get the error.
> 
> David's original question was "if an error occurs on the read(), will
> it return zero?".  To this, I still say NO.  It might return zero
> (based on your knowledge), but it will also return -1 according to the
> doc's and my knowledge.  The safe thing for David would be to check for
> less than or equal to zero.
> 
> Bob
> 
> -----Original Message-----
> From: Patrick Townsend <townsend@patownsend.com>
> To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
> Date: Saturday, June 12, 1999 3:02 PM
> Subject: Re: TCP/IP Sockets
> 
> >
> >I had some help from Michael Mundy at IBM on this issue a while back.
> I
> >hope I'm correctly reflecting what he said:
> >
> >If you are in non-blocking mode on the read (through the use of
> ioctl()
> >or fcntl()) and there is no data to be read, you will get a -1 return
> >code and an errno of EWOULDBLOCK.
> >
> >If you are in blocking mode on the read (the default) and you get a 0
> >return code for bytes read the socket has shut down or disconnected.
> >
> >Patrick
> >
> >Bob Crothers wrote:
> >>
> >> Rich,
> >>
> >> I disagree.  A value of -1 indicates that the operation was
> >> unsuccessful.  A value of 0 indicates the value was successful, but
> 0
> >> bytes of data where received.  Of course, I don't send 0 bytes to
> often
> >> (never), but it still indicates success and you can only check errno
> >> when it is -1.
> >>
> >> Per the "AS/400 Sockets Programming Manual (V3R1)" (SC41-3422-00)
> (And
> >> I very seriously doubt that this has changed since V3R1):
> >>
> >> Section 3.1.16:
> >>
> >> >>The read() function is used to receive data from a file or a
> socket.
> >>
> >> >>Parameters
> >>
> >> >>descriptor
> >> >>    (Input)  The descriptor that is to be read from.  The
> descriptor
> >> >>    points to a file or a socket.
> >>
> >> >>buffer
> >> >>    (Output)  The pointer to a user-supplied buffer in which the
> data
> >> is
> >> >>    to be stored.
> >>
> >> >>buffer_length
> >> >>    (Input)  The length of the buffer
> >>
> >> >>Return Value
> >>
> >> >>read() returns an integer.  Possible values are:
> >>
> >> >>   -1 (unsuccessful)
> >> >>   n  (successful), where n is the number of bytes returned.
> >>
> >> Regards,
> >> Bob Crothers
> >>
> >> -----Original Message-----
> >> From: Rich Duzenbury <rduz@aros.net>
> >> To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
> >> Date: Friday, June 11, 1999 11:16 PM
> >> Subject: RE: TCP/IP Sockets
> >>
> >> >No, I think David is correct here.
> >> >
> >> >OS/400 Sockets programming manual:
> >> >
> >> >Usage notes:
> >> >
> >> >1. For sockets that use a connection-oriented transport service
> (for
> >> example, sockets with a type of SOCK_STREAM), a returned value of
> zero
> >> indicates one of the following
> >> >
> >> >- The partner program has issues a close() for the socket.
> >> >
> >> >- The partner program has issued a shutdown() to disable writing to
> >> the socket.
> >> >
> >> >- The connection is broken and the error was retuened on a
> previously
> >> issued socket function.
> >> >
> >> >- A shutdown() to disable readingwas previously done on the socket
> >> >
> >> >So, all of my socket reads check for error codes (values less than
> 0),
> >> but also the special value of 0 bytes read, and assume the other
> side
> >> unceremoniously dumped us off.
> >> >
> >> >> -----Original Message-----
> >> >> From: owner-midrange-l@midrange.com
> >> >> [mailto:owner-midrange-l@midrange.com]On Behalf Of Bob Crothers
> >> >> Sent: Friday, June 11, 1999 6:51 PM
> >> >> To: MIDRANGE-L@midrange.com
> >> >> Subject: Re: TCP/IP Sockets
> >> >>
> >> >>
> >> >> David,
> >> >>
> >> >> Close, but not quite.  the read() will return a -1 to indicate an
> >> >> error.  At that point, the errno variable (defined in C header
> file
> >> >> errno.h).  Retrieving this value is very easy in ILE/C.  I don't
> >> know
> >> >> how to get it with RPG.  But I could create a tiny service pgm to
> >> >> retrieve it if you would like and nobody comes up with a better
> way.
> >> >>
> >> >> Also note that it depends on how the socket on the other end is
> >> closed.
> >> >> If a close() is issued, then you will get the -1.  But, if the
> other
> >> >> side ends without actually closing the socket (eg: ctl-alt-del on
> >> >> windows), you might not get any indication of a problem.  The
> >> >> SO_KEEPALIVE socket option is SUPPOSED to handle this situation,
> but
> >> I
> >> >> have never gotten it to work on the AS/400 (at least not up to
> >> V3R7).
> >> >>
> >> >> Bob
> >> >>
> >> >> -----Original Message-----
> >> >> From: David Gibbs <David.Gibbs@IL.US.MKS.com>
> >> >> To: 'Midrange Mailing List' <MIDRANGE-L@midrange.com>
> >> >> Date: Friday, June 11, 1999 4:10 PM
> >> >> Subject: RE: TCP/IP Sockets
> >> >>
> >> >>
> >> >> >Folks:
> >> >> >
> >> >> >I'm not 100% sure on this... but I think that, when the remote
> site
> >> of
> >> >> a
> >> >> >TCP/IP connection disconnects abnormally, a read() (on the other
> >> side)
> >> >> will
> >> >> >return zero.
> >> >> >
> >> >> >david
> >> >> >+---
> >> >> >| This is the Midrange System Mailing List!
> >> >> >| To submit a new message, send your mail to
> >> MIDRANGE-L@midrange.com.
> >> >> >| To subscribe to this list send email to
> >> MIDRANGE-L-SUB@midrange.com.
> >> >> >| To unsubscribe from this list send email to
> >> >> MIDRANGE-L-UNSUB@midrange.com.
> >> >> >| Questions should be directed to the list owner/operator:
> >> >> david@midrange.com
> >> >> >+---
> >> >> >
> >> >>
> >> >> +---
> >> >> | This is the Midrange System Mailing List!
> >> >> | To submit a new message, send your mail to
> >> MIDRANGE-L@midrange.com.
> >> >> | To subscribe to this list send email to
> >> MIDRANGE-L-SUB@midrange.com.
> >> >> | To unsubscribe from this list send email to
> >> >> MIDRANGE-L-UNSUB@midrange.com.
> >> >> | Questions should be directed to the list owner/operator:
> >> >> david@midrange.com
> >> >> +---
> >> >>
> >> >
> >> >+---
> >> >| This is the Midrange System Mailing List!
> >> >| To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> >> >| To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> >> >| To unsubscribe from this list send email to
> >> MIDRANGE-L-UNSUB@midrange.com.
> >> >| Questions should be directed to the list owner/operator:
> >> david@midrange.com
> >> >+---
> >> >
> >>
> >> +---
> >> | This is the Midrange System Mailing List!
> >> | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> >> | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> >> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> >> | Questions should be directed to the list owner/operator:
> david@midrange.com
> >> +---
> >
> >--
> >IBM AS/400 communications, FTP automation, and network security
> >software and consulting services.
> >
> >http://www.patownsend.com
> >+---
> >| This is the Midrange System Mailing List!
> >| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> >| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> >| To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> >| Questions should be directed to the list owner/operator:
> david@midrange.com
> >+---
> >
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

-- 
IBM AS/400 communications, FTP automation, and network security
software and consulting services.

http://www.patownsend.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---