Slide 1 Client / Server Paradigm Client / Server Paradigm
Dec 19, 2015
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 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.