1. The Client-Server Model And the Socket API

2. Client-Server (1) The datagram service does not require cooperation between the peer applications but such cooperation is essential for the stream service –The coordination is usually achieved through a client- server model A server starts first and waits to be contacted –It does not know which clients will contact it –It continues to run after servicing one client A client starts second and initiates the connection –It must know what server to contact –It initiates contact only when necessary 2

3. Client-Server (2) When used with the datagram service the client- server model often has request-reply semantics –For example, make a request to the database server in a short message and expect a short message back as a reply –If no reply is received, just repeat the request When used with the stream service – –Once the bi-directional connection is open data can flow from client to server or from server to client –The client and server terms describe who initiates contact 3

4. Client-Server (3) An application may have both server and client relationships to other applications –Circular relationships can lead to a deadlock  A client application may contact multiple server applications during a session A server application may support multiple clients The point here is that the client-server relationship is somewhat of an atomic building block. Applications may have many relationships with other applications and functions as clients or servers depending on the communication 4

5. Client-Server (4) Client and server behaviors are often confused with hardware capability –The terms server or client could therefore mean hardware or software A “server-class” computer may run multiple server applications –The client-server model concentrates traffic at the server Multiple clients may simultaneously contact the same server hardware –This is potentially a network bottleneck 5

6. Client-Server (5) An alternative is the peer-to-peer model –A computer runs both client and server parts of an application –Data is distributed among all of the members of the peer-to-peer network –When the application is acting as a client it contacts multiple applications which act as servers Only a fraction of the data is obtained from any one server application – thus distributing the load –Peer-to-peer was popularized by networks set up to illegally share multimedia files (e.g., Napster) but it can be used for more legitimate purposes 6

7. Client-Server (6) How does a client identify a server? In the IP stack an application service is identified in two steps: –Identify the hardware interface where the service can be reached i.e., the computer where the server is running A computer may have more than one interface and the service may only be “listening” on one interface –Identify which service at that interface is of interest Because the computer may be running multiple services 7

8. Client-Server (7) Identifying the interface? –Each interface is assigned a unique identifier at the Internet layer known as an IP address –The server’s IP address will be the destination address in the IP header –Each computer is also assigned a name The mapping between the names and the IP addresses is maintained in the Domain Name System (DNS) service –Client software accepts the name of the computer where the server is located and silently translates the name to an address using DNS A failure of the DNS service can therefore lead users to believe that the service they are trying to contact has failed 8

9. Client-Server (8) Identifying a service? –Each service is assigned a unique 16-bit identifier known as a port number at the transport layer e.g., email  port number 25, web  port number 80 –When a server starts it registers with its local OS by specifying its port number –When a client contacts a remote server to request service the request contains a port number in the transport-layer protocol header –When a request arrives at a server the transport layer protocol uses the port number in the request to determine which application should handle the request 9

10. Sockets (1) The specifications for the IP stack’s transport protocols do not include an Application Programmer’s Interface (API) A networking API called Sockets was distributed as part of the original UNIX –It has become the de-facto standard API and is now widely available on multiple OSes When an application creates a socket the OS returns a small integer descriptor that identifies the socket –The socket is similar to a file descriptor in UNIX 10

11. Sockets (2) An application creates a socket, and then invokes functions to adjust the socket details and to pass data through the socket –The descriptor is an argument to those other functions –The result it that each function call is relatively simple, but it takes a sequence of function calls to actually pass data The most commonly-used functions are shown on the following slide –Also, the helper functions gethostname, gethostbyaddr and gethostbyname allow an application user interface to use hostnames instead of IP addresses 11

12. Sockets (3) NameUsed ByDescription acceptserverAccept an incoming connection bindserverSpecify IP address and protocol port closeeitherTerminate communication connectclientConnect to a remote application (active open) getpeernameserverObtain client’s IP address getsocketoptserverObtain current options for a socket listenserverPrepare socket for use by a server (passive open) recveitherReceive incoming data or message recvmsgeitherReceive data (message transport) recvfromeitherReceive a message and sender’s address send (write)eitherSend outgoing data or message sendmsgeitherSend outgoing data (message transport) sendtoeitherSend outgoing message (variant of sendmsg) setsocketopteitherChange socket options shutdowneitherTerminate a connection (in one direction, i.e., half-close) socketeitherCreate a socket for use by the other functions 12

13. Sockets (4) The next slide shows the sequence of socket calls made by a typical client and server that use a stream connection –The client sends data first and the server waits to receive data The socket functions used to send and receive messages are more complicated than those used with the stream paradigm because more options are available –The connectionless, one-to-many behavior of the message transport is not as restrictive as the stream transport’s one-to-one connection 13

14. Sockets (4) 14 Illustration of stream socket function calls

15. Sockets (5) The socket API supports two different styles of servers –An iterative server iterates through each client one at a time This is why the API includes a queue for client connection requests –A concurrent server handles multiple clients at the same time The main server process has a listening socket When a connection request from a client arrives the main process creates a child process with its own socket that handles that connection while the main server process continues listening on its socket When the client is finished the child process closes its connection but the main server process continues to run 15

16. Sockets (6) The socket API adheres to the following rules: –The socket implementation uses a reference count mechanism to control each socket The socket exists as long as the reference count remains positive –When a socket is created its reference count is set to 1 –When a program creates an additional thread: The thread inherits a pointer to each open socket the program owns The reference count of each socket is incremented by 1 –When a thread calls close The system decrements the reference count for the socket If the reference count has reached zero, the socket is removed 16