Nonblocking I/O

By default, sockets are blocking.

1. Input operations read
   These include the readv, recv, recvfrom, and recvmsg functions. If there is no data available in the socket receive buffer, we are put to sleep until some data arrives.
   With a nonblocking socket, if the input operation cannot be satisfied , we see an immediate return with an error of EWOULDBLOCK.
2. Output operations
   These include the write, writev, send, sendto, and sendmsg functions. If there is no room in the socket send buffer for a blocking socket, the process is put to sleep until there is room.
   With a nonblocking TCP socket, if there is no room at all in the socket send buffer, we return immediately with an error of EWOULDBLOCK. If there is some room in the
   socket send buffer, the return value will be the number of bytes the kernel was able to copy into the buffer. (This is called a short count.)
3. Accepting incoming connections
   This is the accept function. If accept is called for a blocking socket and a new connection is not available, the process is put to sleep.
   If accept is called for a nonblocking socket and a new connection is not available, the error EWOULDBLOCK is returned instead.
4. Initiating outgoing connections
   This is the connect function for TCP a TCP connect always blocks the calling process for at least the RTT to the server.
   If connect is called for a nonblocking TCP socket and the connection cannot be established immediately, the connection establishment is initiated (e.g., the first packet of TCP's three-way handshake is sent), but the error EINPROGRESS is returned.
   Notice that this error differs from the error returned in the previous three scenarios. Also notice that some connections can be established immediately, normally when the server is on the same host as the client. So, even with a nonblocking connect, we must be prepared for connect to return successfully.
   

Nonblocking connect

When a TCP socket is set to nonblocking and then connect is called, connect returns immediately with an error of EINPROGRESS but the TCP three-way handshake continues. We then check for either a successful or unsuccessful completion of the connection's  establishment using select. There are three uses for a nonblocking connect:

1. We can overlap other processing with the three-way handshake. A connect takes one RTT to complete and this can be anywhere from a few milliseconds on a LAN to hundreds of milliseconds or a few seconds on a WAN. There might be other processing we wish to perform during this time.
2. We can establish multiple connections at the same time using this technique. This has become popular with Web browsers
3. Since we wait for the connection to be established using select, we can specify a time limit for select, allowing us to shorten the timeout for the connect. Many implementations have a timeout for connect that is between 75 seconds and several minutes. There are times when an application wants a shorter timeout, and using a nonblocking connect is one way to accomplish this.

there are other details we must handle:

1. Even though the socket is nonblocking, if the server to which we are connecting is on the same host, the connection is normally established immediately when we call connect. We must handle this scenario.
2. POSIX have the following two rules regarding select and nonblocking connects:
   A TCP socket is writable if there is available space in the send buffer (which will always be the case for a connecting socket since we have not yet written anything to the socket) and the socket is connected (which occurs only when the three-way handshake completes). A pending error causes a socket to be both readable and writable.
   
   1. When the connection completes successfully, the descriptor becomes writable
   2. When the connection establishment encounters an error, the descriptor becomes both readable and writable