RE: what is a reasonable socket select() wait time?

A further point to make is that you should also be prepared to receive
MORE than expected.

If the other side sends more than one logical record of data, you might
receive it all at one time.

Eg:  If the client sends 5 records of 256 bytes each, you might receive
128 bytes, followed by 256 bytes (128 of 1st rcd and 128 of 2nd rcd)
followed by 128 bytes (2nd half of rcd 2) and then 768 bytes (rcds 3, 4
& 5).

Weird combinations like this are more likely when you are sending over
the internet when there is a lot of unknown hardware between the 2
ends.

In my protocols, I send a small header that has info about compression,
encryption, uncompressed length, compressed length of the logical
record and other info useful to me.  Applications all use a common
class that encapsulates all of the above and totally hides how the data
gets buffered/packitized.

This approach has worked well for me over the last 8 or so years I've
been working with TCP/IP.

Even if I wasn't using custom protocols, I'd still encapsulate this
when using delimited protocols such as HTTP etc.

Regards,
Bob Crothers
Cornerstone Communications
http://www.cstoneindy.com




-----Original Message-----
From: mi400-admin@midrange.com [mailto:mi400-admin@midrange.com]On
Behalf Of Rich Duzenbury
Sent: Monday, April 22, 2002 2:33 PM
To: mi400@midrange.com
Subject: Re: [MI400] what is a reasonable socket select() wait time?


>
>Why does the select() periodically fail?  How can my client truly,
TRULY
>determine if more data is available from the server?  Do I need a
non-zero
>wait time?  What is a reasonable value?

I don't think select is 'failing' per se.  There just isn't any data
-yet-.  Lost & retransmitted packets by the underlying transport
mechanism
could cause this, as another poster mentioned.  A busy network might
also
cause select give up before any data is available.

Perhaps I read too much into your message, but I wonder how your actual
protocol is setup.  The receive side of the socket knows how much data
to
expect, right?

If you send a fixed length message, your read loop should loop until a
complete message is read, or an error occurs.

If you send a delimited message - e.g. a null byte at the end of each
message, your read loop should read until the null is located, or an
error
occurs

Otherwise, you could preface a variable length message with the number
of
bytes to follow, and then loop until that many bytes are received, or
an
error occurs.

The point is, the receive loop has to *know* how much data to look for.
Also, the loop must be prepared to receive a message in 'chunks' or
'pieces' by comparing the received count with the requested count, and
acting accordingly by requesting to read the remaining data.

_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
or email: MI400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.