I/O Multiplexing Road Map: 1. Motivation 2. Description of I/O multiplexing 3. Scenarios to use I/O multiplexing 4. I/O Models  Blocking I/O  Non-blocking I/O  I/O multiplexing ( select(..) and poll(..) functions)  Signal driven I/O  Asynchronous I/O 5. Comparison of models

Motivation  Read/write from multiple descriptors?  What if data arrive from both fd1 & fd2 ? If you do recv(fd1,..), then you blocked until something arrives. If something arrives at fd2, you have no idea! Ex: Web client, download accelerator, proxies.  Solution : I/O multiplexing

Description of I/O multiplexing We need  to check both fd1 & fd2  receive from the one which has data.  This is called I/O multiplexing.  Achieved by select and poll fcns.

Scenarios to use I/O multiplexing 1. Client handle multiple descriptors  Ex: interactive input & network socket 2. Client handle multiple sockets  Web client, download accelerator, proxies 3. Server handles both TCP & UDP  DNS listens both TCP53 & UDP53 4. Server handles multiple services or protocols

A note..  These techniques are not limited to network programming.  I/O multiplexing is also used by  File I/O  Interactive I/O  Network I/O

Blocking I/O ApplicationKernel recvfrom system call no ready datagram datagram ready copy datagram copy complete wait for data here copy data from kernel to user return OK process datagram Application blocks here Now let’s talk about this method.  Do you think it is a good approach?  What are pros and cons?

Non-blocking I/O ApplicationKernel recvfrom system call no ready datagram EWOULDBLOCK recvfrom system call no ready datagram EWOULDBLOCK recvfrom system call datagram ready copy datagram process datagram return OK copy complete copy data from kernel to user Process repeatedly calls recvfrom waiting for an OK (polling) wait for data here

Non-blocking I/O cont. Requires socket to be set non-blocking mode. fcntl (stands for file control) sets a socket to non-blocking mode Example: UdpNonblockingIO.c #include int fcntl(int fd, int cmd,...)  returns: depends on cmd if OK, -1 on error.

I/O multiplexing model ApplicationKernel select system call no ready datagram recvfrom return readable system call process datagram return OK copy complete datagram ready copy datagram copy data from kernel to user wait for data here Process blocks while data is copied from kernel Process blocks in select waiting for one of possibly many sockets to become readable

select System Call select allows the process to instruct the kernel to wait for any of multiple events to occur and to wake up the process only when one or more of these events occurs or when a specified amount of time has passed. #include int select(int maxfd, fd_set *readset, fd_set *writeset, fd_set *exceptset, const struct timeval *timeout)  returns: positive count of descriptors, 0 on timeout, -1 on error. struct timeval{ longtv_sec; /* seconds */ long tv_usec; /* milliseconds */ };

select cont. 3 possibilities of timeout 1. Wait forever: NULL timeout argument. 2. Wait up to a fixed amount of time. 3. No wait at all: Return immediately after checking the descriptors. This is called “polling”. both tv_sec & tv_usec are set to “0”.

An example We can call select and tell the kernel to return only when any of the descriptors in the set {1,4,5} are ready for reading. {2,7} are ready for writing. {2,4,5} have an exception seconds have elapsed. Tell the kernel what descriptors we are interested in (for reading, writing, or an exception condition) and how long to wait.

How to specify descriptor set? There are fuctions to set, clear, and query on a descriptor set. Example: selectEx.c void FD_ZERO(fd_set *fdset); /* clear all bits in fdset */ void FD_SET(int fd, fd_set *fdset); /* turn on bits */ void FD_CLR(int fd, fd_set *fdset); /* turn off bits */ int FD_ISSET(int fd, fd_set *fdset); /* is the bit for fd on in fdset? */ fd_set rset; FD_ZERO(&rset); FD_SET(1, &rset); FD_SET(4, &rset); FD_CLR(5, &rset);

poll System Call Very similar to select. fdarray is a pointer to the first element of an array of structures. Each element in the array is a pollfd structure that specifies the conditions to be tested for a given descriptor, fd. Most important events: POLLIN, POLLOUT. #include int poll(struct pollfd fdarray[], unsigned long nfds, int timeout);  returns: count of ready descriptors, 0 on timeout, -1 on error. struct pollfd{ int fd; /* descriptor to check */ shortevents; /* events of interests on fd */ short revents; /* events occured on fd */ };

Signal driven I/O  A signal is a notification to a process that an event has occured.  They are asynchronous. Example:  Pressing ^C while program running.  Child process terminates and kernel sends SIGCHLD signal to parent.

Signal driven I/O cont.  Every signal has a disposition.  We set disposition by calling “ sigaction ” with 3 options. 1. Provide a function (signal handler) for signal occurence. SIGKILL & SIGSTOP signals cannot be caught. 2. Ignore a signal by setting disposition to SIG_IGN. SIGKILL & SIGSTOP cannot be ignored. 3. Set default disposition by SIG_DFL. Example: signalEx1.c (handling ^C ) signalEx2.c (using SIGALRM to perform I/O)

Signal driven I/O cont.  The idea is to set the I/O descriptor for signal driven I/O and then set SIGIO handler calling sigaction.  Whenever the descriptor is ready for reading, the kernel will generate SIGIO signal.  The I/O can then be performed within signal handler.

Signal driven I/O diagram ApplicationKernel Establish SIGIO signal handler sigaction system call initialize return signal handler deliver SIGIO datagram ready system call copy datagram process datagram return OK copy complete Process continues wait for data here recvfrom Process waits copy data from kernel to user This is an advanced I/O model & we will not cover this in this class.

Asynchronous I/O The idea is to start the I/O operation and let the kernel notify us when the entire process is complete (including the copy of the data from the kernel to our buffer). Main difference between signal driven I/O is that with signal driven I/O the kernel tells when an I/O operation can be initiated. But here kernel tells when I/O operation is complete.

Asynchronous I/O diagram ApplicationKernel aio_read no ready datagram datagram ready copy datagram copy complete wait for data here copy data from kernel to user Signal handler process datagram Process continues executing system call return Deliver signal specified in aio_read  Few POSIX systems support asynchronous I/O

Comparison of I/O Models st phase: wait for data InitiateCheck ReadyNotification Initiate 2nd phase: Copy data from kernel to user Complete 1st phase handled differently 2nd phase handled the same (i.e. blocked in call to recvfrom) Handles both phases blockedblocked blockedblocked blockedblocked blockedblocked

Last word The easiest to use among them ◦ Blocked I/O ◦ I/O Multiplexing If your system supports threads, you can emulate other I/O models using multiple threads: ◦ One thread to wait for I/O for first and third models & the other thread doing processing if something needs to be processed. Thus we overlap I/O & computation within a single application.