I / O MULTIPLEXING : THE Select AND Poll FUNCTIONS
It is seen that the TCP client is handling two inputs at the same time: standard input and a TCP socket. It was found that when the client was blocked in a call to read(by calling readline function), and the server process was killed. The server TCP correctly, correctly sends a FIN to the client TCP, but since the client process is blocked reading from the standard input, it never sees the end – of file until it reads from the socket . What we need is the capability to tell the kernel that we want to be notified if one or more I/O conditions are ready (i.e. input is ready to be read, or the descriptors is capable of taking more outputs). This capability is called I /O Multiplexing and is provided by the select and poll functions . There is one more Posix .1g variations called pselect.
I /O multiplexing is typically is used in networking applications in the following scenarios:
• When a client is handling multiple descriptors ( normally interactive input and a network socket), I/O multiplexing should be used. This is the scenario that was described in the previous paragraph.
• It is possible, but rare, ofr a client to handle multiple sockets at the same time. We show an example of this using select in the context of web client
If a TCP
ndles both a listening socket and its connected sockets, I / O
multiplexing is normally used.
• IF a server handles both TCP and UDP, I/O multiplexing is normally used.
• If a server handles multiple services and perhaps multiple protocols, I/O multiplexing us normally used.
It is not restricted only to networking programme, it may be used in any nontrivial application as well.
There are five I /O models in the Unix. These are:
a. Blocking I /O
b. Non blocking I / O
c. I/O Multiplexing (select and poll)
d. Signal driven I/O (SIGIO)
e. Asynchronous I/O (the Posix 1 aio_functions)
There are two distinct phases for an input operation.:
a. waiting for the data to be read and
b. copying the data from the kernel to the process.
Fo ran input operation on a socket the first step normally involves waiting for the data to arrive on the network. When the packet arrives, it is copied into buffer within the kernel. The second step is copying this data from the kernel‘s buffer into our applications buffer.
Blocking I/O Model :
The most prevalent model for I/O is the blocking I/O model, which we have used for all our examples so far in the text.. BY default, all sockets are blocking. Using a datagram socket for our examples we have the scenario as shown below. In UDP the concept of data being ready to be read is simple because either an entire datagram packet is received or not.
IN this example recvfrom as a system call as it differentiated between our application and the kernel.
The process calls recvfrom and the system call does not return until the datagram arrives and is copied into our application buffer, or an error occurs. The most common error is the system call being interrupted by a signal. We say that our process is blocked the entire time from when it call recvfrom until it returns. When recvfrom returns OK, our application processes the datagram.
Non Blocking I/O Model :
When the socket is set to non blocking, the kernel is told that ―when I/O operation that I request cannot be completed without putting the process to sleep, do not put the process to sleep but return an error message instead.‖ The following figure gives the details.
the first three times, when the recvfrom
is called, there is no data to return, so the kernel immediately returns an
error EWOULDBLOCK. Fourth time, when
recvfrom is called, the datagram is
ready, it is copied into our application buffer and the recvfrom returns OK. The application then process the data.
When the application puts the call recvfrom in a loop, on a non blocking descriptors like this, it is called polling. The continuation polling of the kernel is waste of CPU time. But this model is normally encountered on system that are dedicated to one function.