Client / Server Paradigm

1. Client / Server Paradigm

2. 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 Outline:Client / Server Paradigm

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.

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

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.

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.

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).

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.

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

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.

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/)

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.

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.

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.

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).

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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