× 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: "Bob Crothers" <bob@xxxxxxxxxxxxxx>
  • Date: Sun, 13 Jun 1999 12:35:25 -0500

David et al,

Well, I just dug further into my code.

Keep in mind that my conversations are all mine and are not using any
of the "traditional" (HTTP, FTP, etc) IP protocols. As a result, they
are all record oriented.  Streams are just very large records. I have
wrapped the sockets implementation with my own code so that it works
the way I want.  And isolates the application from the sockets
interface.

When I look at my GetSocketsData (which does the read() ), it is only
looking for a -1 as an error, otherwise it returns whatever the read
returned.  However, the caller of GetSocketsData is looking for a <= 0
condition (GetSocketsData is NEVER called by the application).  Just
like you folks are saying.

I think we are dealing with bad or at least "not very clear"
documentation from IBM on this issue.

Looking in Microsoft's documentation on CAsyncSocket::Receive(), I find
the following:

>>If no error occurs, Receive returns the number of bytes received. If
the connection
>>has been closed, it returns 0. Otherwise, a value of SOCKET_ERROR is
returned,
>>and a specific error code can be retrieved by calling GetLastError.

And of course, SOCKET_ERROR is a -1.

However, I do still maintain that you should be looking for a less than
or equal zero, NOT just a zero.  This is especially important in
commercial software (which all in this discussion are writing I
believe).  If the -1 only occurs once every billion reads, how long
does it take for that to happen? With customer  bases of hundreds or
thousands, it will not be long.  And these are the kind of "once in a
blue moon bugs" that are very hard to find.

Bob

-----Original Message-----
From: David Gibbs <David.Gibbs@IL.US.MKS.com>
To: 'Midrange Mailing List' <MIDRANGE-L@midrange.com>
Date: Sunday, June 13, 1999 10:18 AM
Subject: RE: TCP/IP Sockets


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


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


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.