Chapter 29 -- the socket interface

(rev. 01/21/2008)

Notes On Chapter Twenty-Nine -- The Socket Interface

29.1 Introduction -- This chapter discusses:
- concurrency
- Operations that a client or server might use to operate the virtual network implemented by the protocol software.
29.2 Application Program Interface
- The usual way to make an interface between applications and the protocol software is to make a set of functions available to application programmers.
- The protocol software presents a virtual network to the applications. Applications treat the network as a data structure. A data structure has a set of operations. In this context, the set of operations and their arguments (formal parameters) is called the Application Program(er) Interface (API).
29.3 The Socket API
- Communication protocols usually do not specify the API in detail. Different operating systems may offer different API's.
- In TCP/IP networking, the socket API, developed as part of the Berkeley Software Distribution of Unix, has come to be a de facto standard.
29.4 Sockets And Socket Libraries
- In BSD Unix socket functions are system calls.
- In ports of BSD sockets, socket functions are often implemented with library functions -- applications level program code that gets "glued" onto applications programs during the compile/linking phases.
- The library code functions as an interpreter. When the application code makes a call to a socket function, the library code, in effect, translates. The library code executes a series of native system calls in such a manner that the overall effect is to do the task required by the socket function call.
- The compiled image of code that uses sockets may be very big if the socket functionality is in libraries. (However "shared" libraries are common now, as is dynamic loading.)
- In theory an application should port successfully to any platform that supports the same API.
29.5 Socket Communication And UNIX I/O
- Unix takes the approach: "make everything look like a file."
- For example the same operation names {open, read, write, close} that Unix provides for file I/O are also used for network communication.
- When a Unix program calls open(), the operating system returns a small integer like 4 or 5, called a descriptor.
- Subsequently when the Unix program calls read() or write() to do I/O on the file, it uses the descriptor as one of the parameters to identify which file it wants to read from or write to. This is considered a convenience. In particular, function calls don't have to contain path names of files (e.g. "/Users/dept/john/public_html/Classes/scratch/CS3000/Notes")
29.6 Sockets, Descriptors, And Network I/O
- In Unix, a descriptor can also correspond to a socket.
- A socket is a data structure that provides an endpoint of communication. The socket is what the program "listens" to and what it "speaks into." A program uses a socket a lot like a person uses a telephone.
- In Unix an application uses the same functions: {open(), read(), write(), close()} to do I/O on files, on sockets, and even on devices like keyboards, monitors, scanners, and printers.
- In all these cases, after opening the file, socket, or device, the Unix program uses a descriptor when it performs a read, write, or close operation.
- This is very flexible. For example, a single write-statement in a program, when executed, may write to a file, a socket, or a device! It will write to whatever corresponds to its descriptor argument.
29.7 Parameters And The Socket API
- On the other hand, things are not as simple as the information above might lead one to believe. For example, a socket is not really a file.
- There has to be some difference between the set of functions that handle files and the set of functions that handle sockets.
- Unix takes care of this by making a large set of simple special functions available for "configuring" sockets.
- The Unix philosophy is to make a large number of simple functions available for configuring sockets, rather than a small number of complicated ones.
29.8 Procedures That Implement The Socket API
- 29.8.1 The Socket Procedure
  - To create a socket:
```
sd = socket(protofamily, type, protocol) 
```
  - sd (return value) is the descriptor handle for the socket opened.
  - protofamily (input parameter) is the protocol family to be used with the socket -- PF_INET is the value of protofamily used to specify the TCP/IP protocol suite.
  - type (input parameter) tells what kind of communication the socket will use -- common types are SOCK_STREAM for connection-oriented stream transfer, or SOCK_DGRAM for connectionless transfer.
  - protocol (input parameter) specifies the particular protocol to use. (For example, it is possible for a protocol family to contain more than one protocol that provides connectionless service.)
- 29.8.2 The Close Procedure
  - After creating, to terminate use:
```
 close(sd) 
```
  - sd (input parameter) is the descriptor of the socket.
  - The Microsoft Windows Sockets interface does not use close(sd). Instead it uses: closesocket(sd).
- 29.8.3 The Bind Procedure
  - After creating, for a server to request assignment of a port on which to listen:
```
 bind(sd, localaddr, addrlen) 
```
  - sd (input parameter) is the descriptor of the socket.
  - localaddr (input parameter) is a special structure (called a sockaddr) that specifies the local address to be assigned to the socket
    - In the case of TCP/IP this local address is the combination of an IP address and a port number.
    - The special symbolic constant INADDR_ANY is often used as the IP address in case the host is multi-homed and the server wants to accept from all NIC's.
  - addrlen (input parameter) is an integer that specifies the length of the address
- 29.8.4 The Listen Procedure
  - After binding, a server calls listen to place a socket in passive mode for awaiting a a contact from a client:
```
 listen(sd, queuesize) 
```
  - sd (input parameter) is the descriptor of the socket.
  - queuesize (input parameter) specifies a size for the socket's request queue. (Client requests may be queued.)
- 29.8.5 The Accept Procedure
  - After creating, binding, and executing listen() a connection-oriented server that wants to establish a connection with a client does this:
```
 new_sd = accept(sd, caddress, caddresslen) 
```
  - new_sd (integer variable) is the descriptor of a socket to be used for one interaction with one client.
  - sd (input parameter) is the descriptor of the socket on which the server is listening.
  - caddress (output parameter) is a pointer to a sockaddr. When the connection is accepted, the client's address information will go here.
  - caddresslen (output parameter) is a pointer to the length of the client's address.
  - The server can call accept() over and over in a loop as a means of serving one client after another.
  - accept() synchronizes the server with clients. It returns the next client request.
    - if the queue is empty, the server sleeps until a client request arrives (this avoids waste of CPU time).
    - if the queue is not empty, accept() returns the next request immediately,
  - After serving a client, a server thread closes new_sd. If it is the main server thread, it then executes accept() again.
- 29.8.6 The Connect Procedure
  - To establish a connection to a server a client application uses:
```
 connect(sd, saddress, saddresslen) 
```
  - sd (input parameter) is the descriptor of a socket through which the client wants to communicate with the server.
  - saddress (input parameter) is a sockaddr in which the calling client has placed the end-point address of the desired server.
  - saddresslen (input parameter) is the length of the server's address in octets.
  - A client desiring connectionless service also might use connect() as a way to record the server's address in a sockaddr. Afterwards the descriptor of the socket would be the only "address" the client would need to give to send a packet.
- 29.8.7 The Send, Sendto, And Sendmsg Procedures
  - To send an array of octets through a connected socket:
```
 send(sd, data, length, flags) 
```
  - sd (input parameter) is the descriptor of the socket (on the sender's side).
  - data (input parameter) is the base address of the array of octets to be sent.
  - length (input parameter) is the number of octets in the array.
  - flags (input parameter) is an array of bits for specifying certain (e.g. debugging) options.
  - There are also variants of send() called sendto() and sendmsg(). They are for sending data through an unconnected socket.
- 29.8.8 The Recv, Recvfrom, And Recvmsg Procedures
  - To receive an array of octets from a connected socket:
```
 recv(sd, buffer, length, flags) 
```
  - sd (input parameter) is the descriptor of the socket (on the receiver's side).
  - buffer (input parameter) is a base address in the receiver's memory where the incoming octets will be written.
  - length (input parameter) is the number of octets available for the message (buffer size).
  - flags (input parameter) are for controlling aspects (e.g. whether the message remains in the socket).
  - There are variants of recv() called recvfrom() and recvmsg().
    - They are for receiving data through an un-connected socket.
    - They have output parameters that the caller uses to get the endpoint address (e.g. IP address and port) of the sender.
    - They are designed to interoperate well with sendto() and sendmsg().
29.9 Read And Write With Sockets
- A Unix program may use calls to the standard read() and write() functions to do I/O on a socket:
```
 read(sd, data, length) 
```
```
 write(sd, data, length) 
```
- As for other commands sd is the descriptor of the socket, data is the base address of an array of octets and length is the size of the array.
- (Check manuals for the exact meanings of the arguments/parameters.)
- As mentioned before, this usage is very flexible
- However, if sockets are implemented with libraries, this usage can result in "additional overhead in the file I/O of any application that also uses sockets."
29.10 Other Socket Procedures
- getpeername() (What is your name, exactly?) after an accept, "obtain complete address of the remote client that initiated the connection."
- gethostname() (What is my name, exactly?) a process uses this to get info about the host on which it is executing.
- setsockopt() to put values in socket options
- getsockopt() to see current option values
- gethostbyname() to translate a host name to IP address (What is the IP number for this name?).
- gethostbyaddr() to translate an IP address to a hostname (What is the name for this IP number?).
29.11 Sockets, Threads, And Inheritance
- Typically when a mother thread creates a child the reference count of all open sockets is incremented and both mother and child have access.
- In our sample code, immediately after service-thread-creation the mother-server performs a close on the new "service" socket and the child-service thread performs a close on the socket on which the mother-server is listening (the "original" socket). These actions have the effect of decrementing (by 1) the reference count of each of the two sockets.
- The child-service thread will perform a second close on the "service" socket when it has finished performing the service. Thus a socket used to service a specific client exists only until the service thread has finished providing the service to the client.
- The mother-server thread does not perform a close on the socket on which she listens. That way the socket the main server uses to accept connections remains in existence for the lifetime of the server.
29.12 Summary