The Client-Server Model

And the Socket API

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

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

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

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

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

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

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

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

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

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

Sockets (3)Name Used By Description

accept server Accept an incoming connection

bind server Specify IP address and protocol port

close either Terminate communication

connect client Connect to a remote application (active open)

getpeername server Obtain client’s IP address

getsocketopt server Obtain current options for a socket

listen server Prepare socket for use by a server (passive open)

recv either Receive incoming data or message

recvmsg either Receive data (message transport)

recvfrom either Receive a message and sender’s address

send (write) either Send outgoing data or message

sendmsg either Send outgoing data (message transport)

sendto either Send outgoing message (variant of sendmsg)

setsocketopt either Change socket options

shutdown either Terminate a connection (in one direction, i.e., half-close)

socket either Create a socket for use by the other functions

12

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

Sockets (4)

14

Illustration of stream socket function calls

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

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