I/O multiplexing is the capability to tell the kernel that we want to be notified if one or more I/O conditions are ready, like input is ready to be read, or descriptor is capable of taking more output.
Scenarios is which I/O multiplexing is used -
- When client is handling multiple descriptors (like standard input and network socket).
- When client handles multiple sockets at the same time, example - Web client.
- When TCP server handles both listening and its connected sockets.
- When server handles both TCP and UDP.
- When server handles multiple services and perhaps multiple protocols.
I/O Models
There are 5 I/O models -
- Blocking I/O
- Non-blocking I/O
- I/O multiplexing
- Signal driven I/O
- Asynchronous I/O
There are two phases for any input operation -
- Waiting for data to be ready
- Copying data from kernel to process
Blocking I/O Model
By default, all sockets are blocking.
We use UDP in this diagram because it's easier, as we only have to deal with sending and receiving datagrams.
There is a switch from running in the application to running in the kernel, and returning back to application.
Most common error occurring is when system call is interrupted by a signal.
Non-blocking I/O Model
When we set a socket to nonblocking, we tell the kernel that if an I/O request from me will put the process to sleep, return an error instead of blocking the process (putting the process to sleep).
This method is called polling. It is often a waste of CPU time, but sometimes used on system dedicated to one function.
I/O Multiplexing Model
Disadvantage - select requires two system calls instead of one.
Advantage - We can wait for more than one descriptor to be ready.
Another alternative is using multithreading. Instead of using select to block on multiple file descriptors, the program uses multiple threads (one per file descriptor), and each thread is then free to call blocking system calls like recvfrom.
Signal Driven I/O Model
Signals can tell the kernel to notify user process with SIGIO signal when descriptor is ready.
First enable the socket for signal driven I/O and install signal handler using sigaction system call. Return from this system call is immediate and our process continues, it is not blocked. When datagram is ready to be read, SIGIO signal is generated for our process. We can either read the datagram from the signal handler by calling recvfrom and then notify the main loop that data is ready to be processed, or we can notify the main loop and let it read the datagram.
Advantage - process is not blocked while waiting for data to arrive, can continue executing.
Asynchronous I/O Model
It works by telling the kernel to start operation and notify the process when it's complete, unlike signal driven I/O where kernel notifies when process is initiated.
Monday, 26 September 2016
