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

Hi Gene,

 Comments in-line...

On Fri, 19 Apr 2002 Gene_Gaunt@ReviewWorks.com wrote:
>
> Question 1:
>
> The API reference for the socket select() wait time parameter says,
>
> "A time to wait of 0 is allowed; this returns immediately with the current
> status of the sockets."
>
> What is this "current status" that gets returned?
>

The select() APIs 2nd, 3rd, and 4th parameters are used to indicate which
sockets you want to wait for events on and/or check the status of.  Each
is a string of bits (in integer form) and each bit represents one
descriptor.

On input, each of these parameters indicates which descriptors you're
interested in the status of.  And on output, the API modifies the
parameter to show the status of each.

By status, I mean "is readable", "is writable" and "has exceptional
condition pending", respectively, for each of the parameters.

Does that make sense? (my wording seems somewhat awkward)

In other words, if you wanted to know immediately if a socket has data
to be read, you would set the bit for that descriptor in a "read set"
variable, call select with a timeout of 0, and then check if that bit
is still set.   If it is, the socket is readable.

>
> Question 2:
>
> Will a non-zero select() wait time value slow down an application, if our
> actual receive data length is less than our default TCP receive buffer size
> SO_RCVBUF (which is 8192 bytes), and our allocated receive data length is
> greater than 8192, and no multiplex I/O occurs?

Select() pays no attention to the length of your receive buffer or
receive data length.  It just returns as soon as there's any type of
event.

In other words, select returns as soon as one of these conditions
is true:

  1) Your read_set is not-null, and there's at least one byte in
     the receive buffer.

  2) Your write_set is not-nulll, and there's at least one byte free in
     the send buffer.

  3) Your exception_set is not-null and there's at least one byte of
      out-of-band data to read.

  4) Your timeout is not-null and the amount of time you've
      specified as elapsed.


Or are you asking if it's inefficient to call recv() with a buffer that's
smaller than the receive buffer?   Yes, it's more efficient for the buffer
to be the full size -- so that if the data's there, you read it all right
away, rather than calling it twice.  Obviously, you'll see a performance
degradation if you read one byte at a time -- obviously looping 8,192
times to copy one byte from storage will take longer than a copying an 8k
block once.  But, as long as the buffer isn't TOO tiny, the difference
isn't noticable, since the network is the bottleneck anyway.


I hope that answers your question, I'm still not 100% sure what you're
asking in question #2 :)