Slide 1

Client / Server ParadigmClient / 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 Modelof 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 Modelof Interaction:

• Clients:– Initiate communication.– Are often easier to built than servers since they

usually do not require special system privileges.

Slide 5

Client / Server Modelof 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 / ServerPoints 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 / ServerPoints 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

Client1

Client2

Clientn

Server

...

(a)

(b)

Slide 10

Standard vs. Non-standardClient 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.

(http://hertz.njit.edu:80/~dzt8474/)

(http://hertz.njit.edu:8000/~dzt8474/)

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 InComputer’s Operating System

Application Program Code

Library Routines Used

application program bound with library routines it calls

System Calls: