|
> 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. Actually, Bob, it wasn't a question at all... my statement was ACTUALLY in reply to a discussion on the RPG400-L list (sorry, my fumble fingers)... where someone was looking for a way to determine if the remote system had disconnected. I researched the results of the read() function and found that it returns the number of bytes read, < 0 on error, OR ZERO IF AND END OF FILE CONDITION EXISTS (NO MORE DATA CAN BE EXTRACTED FROM THE SOCKET) [this is from Internetworking with TCP/IP V3 by Comers & Stevens]. Correlating this with the IBM Sockets manual, I figured that a dropped connection would result in read() returning zero. This was actually research done to confirm what I actually observed in recent testing. I had a program that initiated contact with a remote server, but the server went casters up... the client was in a very tight loop where the read() function was always returning zero. Now my read routine tests for total byte count = zero and bytes read = 0, in which case it will return an error indicating end of file (remote side disconnected). david > > 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 > +--- > +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.