× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: TCP/IP Sockets
  • From: Patrick Townsend <townsend@xxxxxxxxxxxxxx>
  • Date: Sat, 12 Jun 1999 18:27:34 -0700
  • Organization: Patrick Townsend & Associates, Inc.

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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.