|
Tim, We are not in disagreement. What you've said is exactly what I was trying to say. I may have added some confusion into the picture by talking about non-blocking reads, but the behaviour you describe is exactly what I've found, too, and what the IBM'er (Mike Mundy) was trying to teach me. Patrick Tim McCarthy wrote: > > I missed the original post but here goes. Patrick, I hate to disagree > with an IBM'er :) but in my experience blocking is not the determining > factor here. There are other ways to get a -1 return code on a read even > with blocking on - in fact a disconnect before a read would NOT block > therefore EWOULDBLOCK is not returned. Even more curiously, reads > following a disconnect can succeed with a zero result even with no > blocking! Even if EWOULDBLOCK was returned it really doesn't tell you > anything about the state of the connection just that there is no data > currently buffered from the remote. The remote could have just sent > data. Whether you get a 0 or -1 as a result of a remote disconnect on a > READ depends on a variety of peculiar circumstances. I've found that if > I send a steam of data prior to performing a series of reads I will get > a -1 return code on a read when a disconnect is detected. If my program > performs reads from a socket only, I get 0 returned. SO_KEEPALIVE would > be the obvious answer to this problem but like Bob I've never been able > to get it to work either. > > Tim > > -----Original Message----- > > From: Patrick Townsend [SMTP:townsend@patownsend.com] > > Sent: Saturday, June 12, 1999 12:09 PM > > To: MIDRANGE-L@midrange.com > > 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 +---
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.