Unit-3 The Client Server Paradigm PDF

Unit-3 The Client Server Paradigm  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor R...

Unit-3 The Client Server Paradigm  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor Riddhi Joshi 2  Background The term client-server has multiple meaning in computing. It can refer to a network architecture where the computers on a network function in different roles in order to share resources. In a Client-Server architecture, a computer is called a server if it is dedicated to managing resources such as printers or files so that other computers, called clients, can access those resources through the server. The client-server architecture, although related to the client-server paradigm. Asst. Prof. Riddhi Joshi 3  In distributed computing, the client-sever paradigm refers to a model for network applications where processes play one of two different roles: a server process, also called a server for short, is dedicated to managing access to some network service, while client processes, called clients for short, access the server to obtain a network service. Note that in client-server distributed computing paradigm, the term refer to processes. A server process runs on a network-connected computer, which we will refer to as the server host, to manage a network service provided by that host.  Note that it is possible for the server host to provide other network service that are managed by other server processes. A user, typically one using another computer, which we will call the client host, makes use of a client process to access a particular service. It is possible for other client processes to run on the client host at the same time, but the appropriate client processes must be used to access a particular service. Server Client Host Host A Client Server Distributed Computing Paradigm  The Client Server model is designed for providing network services, which were, and still are the most popular application of distributed computing. By network service we mean a service provided to allow network users to share resources. Such resources may be as trivial as the time of day or as complex as the files in the file system of the server host or data from a database system. Over the years many such network services have been standardized on the internet: telnet, which allows remote logon to a server host; ftp, for sending and receiving files from a server host. Daytime, which provides a timestamp obtained from a server host; and the world wide web, for fetching web contents via a server host.  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor Riddhi Joshi 8  Client-Server Paradigm Issues Where as the concept of the paradigm is simple, in actual implementation there are a number of issues that must be addressed. 1. A Service Session In the context of the client-server model, we will use the term session to refer to the interaction between the server and one client. The service managed by a server may accessed by multiple clients, when serviced by the server, engages in a separate and independent session with the server, during which the client conducts a dialog with the server until the client has obtained the service it desires.  Start Service Accept a client’s request for a session Conduct a session with the client The execution flow of the server process.  2. The Protocol for a service A protocol is needed to specify the rules that must be observed by the client and the server during a session of the service. Such rules include specifications on matters such as (1) how the service is to be located. (2) the sequence of interprocess communication, and (3) the representation and interpretation of data exchanged.  3. Locating the service A mechanism must be available to enable a client process to locate a server for a given service. In the simplest scheme, the service location is static and can be identified using the address of the server process in terms of the host name and protocol port number assigned to the server process. This is the scheme used for internet service, where each internet service is assigned to a specific port number. In particular, a well-known service such as FTP, HTTP, or telnet is assigned a default port number that is reserved on each internet host for that service.  For example, the FTP service is assigned two port numbers: TCP 20 and 21. HTTP is assigned to the TCP port 80. At a higher level of abstraction, a service may be identified using a logical name registered with a directory or a registry. The logical name will need to be mapped to the physical location of the server process. At a higher level of abstraction, a service may be identified using a logical name registered with a directory or a registry. The logical name will need to be mapped to the physical location of the server process. If the mapping is performed at run time, then the service's location will be dynamic, which is said to be location transparent.  4. Interprocess Communication and Event Synchronization In the client-server model, the interaction of the process follows a request-response pattern. During a service session, a client makes a request to the server, which replies with a response. The client may make a subsequent request, followed by a reply from the server. This pattern may repeat indefinitely until the session is concluded. For each request issued, a client must wait for the reply from the server before it can proceed further.  For Example, one of the simplest network service is the Daytime service, whereby a client process simply obtains a timestamp from the server process. Translated into plain English, the dialog during a service session of this protocol proceeds as follows: – Client: Hello, here. May I have a timestamp please? – Server: Here it is: Likewise, the dialog in a world wide web session proceeds as follows – Client: Hello here. – Server: Okay, I am a web server and speak protocol HTTP 1.0 – Client: Great, please get me the web page index.html at the root of your document tree. – Server: Okay, here’s what’s in the page (content follow) Client Serve Time r Request 1 Response 1 Request 2 Response 2 Request 3 Response 3  Client or server program for this service is expected to adhere to the specification for the protocol, including how the dialog of each session should proceed. Among other things, the specification defines (1) the sequence of interprocess communication between the client and the server (2) the syntax and semantics of each request and response and (3) the action expected of each side upon receiving a particular request of response. Again using the simple Daytime service as an example, the protocol specifies the following.  There is no need for any syntax in the request from the client, as its contact with the server automatically implies a request for time. The response is a timestamp as a character string formatted according to the specification of the protocol.  A sequence diagram is a good way to document interprocess communications during a service session Client Serve r timesta mp The Client-Server distributed computing paradigm  5. Client server protocol Data Representation Part of the specification of a protocol is the syntax and semantics of each request and response. The choice of data representation depends on the nature and the needs of the protocol. Representing data using text (character strings) is common, as it facilitates data marshalling and allows the data to be readable by human. Most well known Internet protocols are client-server, request-response, and text-base.  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor Riddhi Joshi 22  Software Engineering for a Network Service There are two sets of software involved: one for the client process, The other for the server process. The set of software needed on the client host to support a service or application, including the client program and its run-time support, is sometimes referred to as the client-side software, As opposed to server side software, which includes the server program and all the run-time support that it needs. Assuming that the protocol is well defined and understood, it is possible for the software of both sides to be developed separately and independently.  Software Architecture We introduced a three-layer software architecture of network applications, wherein the functionalities of each application can be divided into three layers: presentation, application, and service. Accordingly, the software architecture of an application built using the client-server model, or a client-server application. – Presentation Layer: On the server side, a user interface (UI) is needed to allow the server process to be started; typically, a command-line execution is sufficient. On the client side, a user interface needs to be provided by the client process.  Software Architecture Using such an interface, a user on the client host may request the service and receive the response from the server. In our sample code, we will use a text-mode user interface for simplicity, but a graphic user interface or a web page can be used instead. – Application logic layer: On the server side, the time of day needs to be obtained from the system and sent to the client host. On the client side, the request from the user will need to be forwarded to the server, and the response from the server will need to be displayed to the user. – Service Layer: The service required to support the application are (1) on the client side, a readout of the server’s  Software Architecture The functionalities of the three layers must be present in the combined software. Some of the functionalities belong in the client, some in the server. For large-scale applications, it is advisable to design the software so that the functionalities of the three layers are encapsulated in separate software modules.  Software Architecture Client Side Software Server Side Software Presentation Presentation Login Login Application Logic Application Logic Services Logic Services Logic Software Architecture for Client-Server Application  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor Riddhi Joshi 28  Connection oriented and connectionless server The Internet protocol Echo is the basis for a well-known Internet service. The Echo protocol simply allows a client to send one text line to the server at a time, receiving an echo of each line from the server. The protocol uses an Echo server on any Internet host, as a temporary server when a software engineer is developing a client for another protocol. There are two implementations of the service: one using a connectionless server and the other using a connection oriented server.  Connectionless Echo Client Server Connectionless Echo Client Server The Echo Client The presentation logic for the client is encapsulated in the EchoClient1 class, which provides the user interface for prompting for the server information and then, using a loop for the text lines to send to the Echo server. The sending of the text string and receiving of the echo in return is handled by a method, getEcho, of the EchoClientServer1 class. The EchoClientHelper1 class provides the application logic for the client. An instance of this class is created by each client process, which holds the address of the server host as well as a reference to the socket used by the client for IPC. The getEcho method uses the socket to send a line to and then receive a line from the server. Finally, the close method closes the socket.  Connectionless Echo Client Server Connectionless Echo Client Server The Echo Server EchoServerl.java combines the presentation logic and application logic for the server. In each iteration of the forever loop, the server reads a line from the socket and then writes the line back to the socket, addressing the reply to the sender. Since there is no connection involved, it is possible for the server to interact with different clients in successive iterations, resulting in interleaved concurrent service sessions. Figure illustrates a scenario wherein two concurrent clients of this implementation, A and B, interleave their interactions with an instance of EchoServer1. Connectionless Echo Client Server  Connection Oriented Echo Client Server The implementation of the presentation logic (in EchoClient2 and EchoServer2) is unchanged from EchoClient1 and EchoServer1 in the previous example, but the application logic in EchoClientHelp2 and EchoServer2) as well as the service logic (in MyStreamSocket) are different (since stream-mode socket is used instead of datagram socket). Note that in EchoClientHelper2 the connection to the server is performed in the constructor, while each round of message exchange is provided via the getEcho method. A method, done, is used to transmit the end-of-session message (containing a single period) to the server before the client-side socket is closed. In EchoServer2, a connection socket is first created to accept connections. For each connection accepted, the server continually receives a message and echoes it via the data socket attached to the connection, until the end- of-session message is received. At the end of the session,  Connection Oriented Echo Client Server Throughout a session, the server maintains its connection with the client and exchanges data with the connected client via a data socket dedicated to that client. If another client connects to the server while it is already occupied with a session, the client will not be able to exchange data with the server until the server has completed the current session. Figure 5.7 shows the sequence diagram of two sessions conducted when client 2 attempts to connect to the server while client 1 is being served. Note that there is no interleaving of the sessions in this case. Connection Oriented Echo Client Server  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor Riddhi Joshi 36  Iterative server and Concurrent server With a connection-oriented server such as DaytimeServer2 and EchoServer2, there is no overlapping of client sessions, since the server is limited to exchanging data with a client whose connection it has accepted. Such a server is said to be an iterative server, since it services one client at a time. When requesting service from a popular iterative server, a client will be blocked until all preceding clients have been served. The result can be a significant blocking time if the service sessions are lengthy, such as in the case of a file transfer protocol. Suppose each session can be expected to last ‘t’ time units and that ‘n’ clients have requested connection at a given time. Disregarding other delays for the sake of simplicity, the next client who requests connection can expect to be  Iterative server and Concurrent server The solution to this problem is to introduce concurrency to the server, resulting in a concurrent server. A concurrent server is capable of conducting multiple client sessions in parallel which can be provided using threads or using asynchronous IPC operations. Similar to iterative servers, there are concurrent servers, which use a single connection socket to listen for connections. But a concurrent server creates a new thread to accept each connection and to conduct a service session with the connected client; the thread is terminated upon the conclusion of the session. Figure 5.8 shows the sequence diagram for two concurrent sessions. With a concurrent server, a client will not have to wait long for its connection to be accepted; Iterative server and Concurrent server  Roadmap Background Client Server Paradigm Issues Software Engineering for a Network Service Connection-Oriented and Connectionless Server Iterative Server and Concurrent Server Stateful Servers Asst. Professor Riddhi Joshi 40  Stateful Server Both the Daytime protocol and the Echo protocol belong in a category of protocols known as stateless protocols, as opposed to stateful protocols. A protocol is stateless if no state information needs to be maintained by the server. Such is the case with the Daytime protocol, where the server merely sends a timestamp obtained from the system to each client; and also with the Echo protocol, where the protocol only requires that the server echo each message it receives. In either protocol, the task performed by the server is independent of its state, such as how long the server has been in service or which client it is serving. A stateless server is one that provides a service according to a stateless protocol and hence does not have to maintain any state information, as in the case of  Stateful Server Global State Information The global state information is maintained by the server for all the clients throughout the lifetime of a server. For example, suppose a protocol, which we will call the counter protocol, requires that a server maintain a counter initialized to 0. Each time the server is contacted by a client, it increments the counter by 1 and sends the current value of the counter to the client. To provide such a service, the server must have the value of the counter placed in some storage where it can be retrieved and updated throughout the execution of the server. For a simple counter, the storage may be implemented using a variable of primitive data type in Java. For more complex state information, the storage may be  Stateful Server Session State Information For some protocols or applications, there is a need to maintain information specific to a client session. Consider a network service such as ftp. A file is typically transferred to blocks, requiring several rounds of data exchanges to complete the file transfer. The state information of each session includes: 1. The name of the file being used 2. The current block number 3. The action (get, put, etc) being performed on the file  Stateful Server There are at least two schemes to maintain the session state data. Stateless Server: In one scheme, the session state information may be maintained by the client so that each request contains the session state information, allowing the server to service each request in accordance with the state data sent in the request. By requiring the client to maintain the session data, this scheme allows the server to process each request in the same manner, and thereby reduces the complexity of its application logic. Such a server is known as a stateless server. Stateful Server: In the second scheme, the session state information may be maintained by the server, in which case the dialog during a session may proceed roughly as follows: With this scheme, the server keeps track of the progress of the session by maintaining the session state. Such a Stateful Server