select allows you to check three arrays of file descriptors to see if any of them have data to be processed. Nearly anything can be mapped to a file descriptor: input/output streams, sockets, error streams, etc.

Select also allows us to specify if we want it to block until something arrives on at least one of the descriptors it's monitoring, or if we want a specified timeout interval (so select waits that amount of time before giving up and sayinig no one has anything for us).

It is up to us to provide select with five parameters that we have initialized in advance:

• the largest file descriptor id being 'listened to' (they're each stored as an int, so one of them will definitely be the biggest!)
• a set of 'read from' file descriptors (our recv socket descriptor belongs in here). This is of type fd_set, can be cleared using FD_ZERO and an item can be added to it using FD_SET. (See examples in the source code itself.)
• a set of 'write to' file descriptors, we'll use 0 since we're not writing to anything in the simple server
• a set of 'error' file descriptors to check, again we'll use 0 since we don't have any in our example
• a timeout value, passed as a pointer to a struct of type timeval (it has fields tv_sec and tv_usec to describe the timeout duration in seconds and microseconds. If a NULL value is passed it is treated as 'wait forever or until something arrives', i.e. make select blocking.

Select then returns (after the timeout period or when something has arrived) the actual number of file descriptors that have some data ready.

Concerns:

While it probably won't become apparent in today's experiments, select will notify you when anything has arrived on the source in question.

In the case of sockets for udp communication, this will say true even if only part of the message has arrived, whereas recvfrom only gives you a positive result when the complete message has arrived.

If you are grabbing bytes as soon as select says anything is there, then you have to be prepared to grab a message in pieces, and for the possibility that you also grab part of the next message arriving on the socket!

Sample code:

The 'listening' code from lab 2 has been revamped here: server.C, to include an example of select (in the processMessages routine).

Note the steps taken in

• setting up the timeout,
• clearing and setting the selectList of things to check,
• making/checking the actual call to select

It is also worth noting that the revised server.C eliminates the 'blocking' parameter from the processMessages call.

Objectives:

First, compile and verify that the select statement in server.C actually works the way you expect. (The client code that works with this is from lab 2.)

Next, try setting up an array of multiple sockets to listen to (e.g. listen on a couple of ports) and add all of them to the fd_set.

Remember maxID should be set to whichever socket has the highest value, and FD_ISSET can be called on each of your socket descriptors to find out which one actually got something.