Home | | Network Programming and Management | I/O Multiplexing : the Select and Poll Functions

Chapter: Network Programming and Management : Application Development

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.

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 server handles 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.

 

I/O Models:

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.





During 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.



Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Network Programming and Management : Application Development : I/O Multiplexing : the Select and Poll Functions |


Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.