SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Wed, 3 Jun 1998 08:51:28 PST8PDT
From:	MDINET!ELMONTE!TomE@mdipo.attmail.com (Emerson, Tom # GPS-MDI)
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com (scoug-programming@scoug.com)
Subject:	SCOUG-Programming: Summarizing

Content Type: text/plain

-----Original Message-----
From: Rollin White [SMTP:attmail!internet!scoug.com!rollin]
Subject: SCOUG-Programming: Summarizing

You guys were busy yesterday.

The discussion evolved in the right direction. recv() is not guaranteed
to
receive all of the data from
a send() call. Also, what happens if the client decides to make one
send()
call for each character
(pefectly legal!).

Let's take a step back and come up with a slightly formal definition of
GetLine(). We can either
define it, similar to how I have previously defined it. Or, a strategy I
sort of like in other APIs, is the
name it and have it follow rules similar to fgets().

Let's proceed with with our definition of GetLine(). It must:

1. Read and return a pointer to a line of data received on the specified
socket.
2. Remove any line delimiters (CR, LF, or both)
3. Must not modify the line data in any other way
4. Be able to indicate a timeout or disconnet condition

What else?
----- end original message -----

5. Buffer received data (beyond the line terminator) for a SUBSEQUENT
call to getline(); then, of course, on that subsequent call it should
append any newly received data to the existing buffer

6. (actually, "4a.") gracefully deal with any errors other than timeout
or disconnect [although, off the top of my head I'm not sure what those
might be]

Do we want a seperate function for reading a "block" of data from a
socket? Because the "socket" to read from is passed as a parameter,
there might be a temptation to use this function for the data channel.
However, line terminators, nulls, and other hard-to-deal-with characters
CAN occur as part of the data flow when in "binary" mode. Since the
underlying logic for both of these functions is the same (i.e., read &
buffer until some condition or an error occurs), passing what we expect
the "condition" to be as an input parameter might be a reasonable
approach. For instance: include a "number of characters to receive"
parameter -- if it is zero, receive characters until a standard line
terminator is found (and strip the terminator). If non-zero, it
indicates the number of characters to receive REGARDLESS of line
termination (and nothing should be stripped out).

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 03 | June | 1998 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.