Slide 1 Client / Server Paradigm

Slide 2 Outline: Client / Server Paradigm Client / Server Model of Interaction Server Design Issues C/ S Points of Interaction Complexity of Servers Connectionless vs. Connection-Oriented Interaction Stateless vs. Stateful Servers

Slide 3 Client / Server Model of Interaction: Primary pattern of interaction among applications is the client-server paradigm (C/S). The C/S paradigm uses the direction of initiation to categorize whether a program is a client or a server. Depending upon the process and need, a server may at some point become a client.

Slide 4 Client / Server Model of Interaction: Clients: –Initiate communication. –Are often easier to built than servers since they usually do not require special system privileges.

Slide 5 Client / Server Model of Interaction: Server: –Any program that waits for incoming communication requests from a client and performs the requested service. –Usually require system privileges, so when designing them, you must be careful not to pass those privileges on to the client.

Slide 6 Server Design Issues: Issues that must be handled when designing (programming) servers: –Authentication - verify identity of the client. –Authorization - permission to request the service. –Data Security - prevent data from becoming compromised. –Privacy - preserving unauthorized access. –Protection - preventing applications from abusing system resources.

Slide 7 Client / Server Points of Interaction: Server: –Continuously executes (before and after requests arrive). Client: –Makes the request. –Waits for a response. –Terminates the connection (when it no longer needs the service).

Slide 8 Client / Server Points of Interaction: Server: –Waits for requests at a well-known protocol port that’s been reserved for it’s specific service. Client: –Allocates an arbitrary (unused and non- reserved) protocol port for it’s communication. –Only one of two end ports need be reserved.

Slide 9 Applica- tion 1 Applica- tion 2 Client 1 Client 2 Client n Server (a) (b)

Slide 10 Standard vs. Non-standard Client Software: Two classes of services exist: –Standard Application Services: Consist of those services defined by TCP/IP and are assigned well-known (universally accepted) protocol port numbers. –Non-Standard Application Services: Are locally defined by sites. This distinction is only important when applications are to communicate outside of a local environment.

Slide 11 Parameterization of Clients: Fully parameterized clients allow a user to specify the protocol port, as well as other input parameters. Doing so does not restrict applications to any specific port, even though it may always use a well-known port number in practice. ( (

Slide 12 Complexity of Servers: Servers need to accommodate multiple, concurrent requests. Servers usually have two parts: –Single master which accepts new requests. –Multiple slaves (child processes) which handle those requests.

Slide 13 Complexity of Servers: Steps taken by a Master Server: –Opens a well-known port (socket open and bind). –Waits for a new client’s request (socket listen). –Chooses a new local port for the client to connect over. –Spawns new concurrent slave to service the client over the new port (socket accept). –Goes back to waiting for requests while slave processes handle the requests.

Slide 14 Complexity of Servers: Servers are usually more difficult to build than clients since servers must: –Handle concurrent requests. –Enforce all access and protection policies of the computer system on which they run. –Must protect themselves against all possible errors, such as malformed requests and requests causing it to abort.

Slide 15 Connectionless vs. Connection-Oriented Interaction: Clients and servers communicate using: –UDP - connectionless interaction (unreliable delivery of messages). –TCP - connection-oriented interaction (reliable delivery of messages).

Slide 16 Connectionless vs. Connection-Oriented Interaction: Designing client / server applications: –Connection-oriented protocols: Make programming simpler. Relieves the responsibility of detecting and correcting errors.

Slide 17 Connectionless vs. Connection-Oriented Interaction: –Programs only use UDP (connectionless service) if the application protocol: Handles the reliability, Requires hardware broadcast or multicast, Or the application cannot tolerate virtual- circuit overhead delays.

Slide 18 Stateless vs. Stateful Servers: The information a server maintains on the status of ongoing interactions with it’s clients, is called state information. Keeping small amounts of state information in a server can: –Reduce the size of messages sent. –Allow the server to respond quickly to requests.

Slide 19 Stateless vs. Stateful Servers: The motivation for statelessness lies in protocol reliability. State information can become incorrect if: –Messages are lost, duplicated, or delivered out- of-order. –The client crashes and reboots.

Slide 20 Stateless vs. Stateful Servers: State Tables State Tables: –Are maintained to allow communication without having to pass filenames or extra identification information in each message.

Slide 21 Stateless vs. Stateful Servers: State Tables When a client opens a remote file, the server adds an entry in the state table with information that includes: –Name of file. –File handle (small integer used for identification). –Current position in the file.

Slide 22 Stateless vs. Stateful Servers: State information - can improve efficiency, but can be difficult to correctly maintain if the client and server use UDP to communicate. Stateless Servers: –Rely on the application protocol to assume the responsibility for reliable delivery –Should give the same response no matter when or how many times a request arrives.

Slide 23 Stateless vs. Stateful Servers: In a real internetwork, where machines crash and reboot, and messages can be lost, delayed, duplicated, or delivered out-of-order, stateful designs lead to complex application protocols that are difficult to: –Design –Understand –Program correctly.

Slide 24 Program Interface to Protocols: Routines the operating system supplies, define the interface between the applications and protocol software (Application Program Interface - API). Advantages: –Provides flexibility and tolerance. –Allows procedural or message-passing interface styles. Disadvantage: –Interface details can differ between vendors where applications may not correctly interoperate.

Slide 25 System Calls: System calls: –Transfer control between an application program and the operating system procedures that supply services. Applications that need access to system resources (including the network connection) make system calls.

Slide 26 System Calls In Computer’s Operating System Application Program Code Library Routines Used application program bound with library routines it calls System Calls: