RE: Socket receive completely read

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Aaron,
This is the nature of sockets in general.  Because the network can break
packets up you never really know if the sender is done sending or not.  For
a worse case scenario, consider a chat application.  If you listen for CR/LF
as the 'end of data' marker, what do you do if the typist walks away from
the screen for an hour in the middle of a sentence?

If you program both ends of the connection, there are several ways you can
avoid this problem.  You can have the sender transmit a distinct 'end of
data' marker like $DONE$.  The listener keeps listening until it has
accumulated all of the characters in the delimiter.

You can send a length as the first characters; sort of a 'this message is
THIS long.'  The sender and listener both agree on how many bytes comprise
the length, say 5.  Then the listener keeps listening until it has
accumulated _length_ bytes.

This "chunking" methodology is a variant of the latter.  The sequence you
have is already translated into EBCDIC and I think should be broken down as
follows: "0D 25 F1 0D 25 25 0D 25 F0 0D 25 0D 25"

0D 25 - prev data?
F1 - chunk size (1 byte)
0D 25 -chunk size terminator
25 - the chunk
0D 25 - end of chunk
F0 - chunk size (0 bytes - final chunk)
0D 25 - end of chunk size
0D 25 - end of chunk trailer (empty line)

So the algorithm you need to implement for this seems to be:
1) Accumulate "chuck size" bytes until CRLF
1a) If "chunk size" = 0, exit to (3)
2) Read "chunk size" bytes
2a) Read CRLF
2b) Repeat to (1)
3) Read CRLF
4) Exit
  --buck