Client / Server Paradigm
LESSON 20

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.
• Clients:
  • Initiate communication.
  • Are often easier to built than servers since they usually do not require special system privileges.
• 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.
  

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.
  
  
• Key terminology concept:
  • If a machine's primary purpose is to support a particular server program (or multiple services), the device is commonly referred to as a server.

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

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

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.

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

  (telnet hertz.njit.edu 25)

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.

  (1 request = 1 slave)

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

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

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).
• Designing client / server applications:
  • Connection-oriented protocols:
    • Make programming simpler.
    • Relieves the responsibility of detecting and correcting errors.
  • 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.

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

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

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

Servers as Clients:

• A server may need to access network services that require it to act as a client as well as a server.
• It is not uncommon to find a server for one application acting as a client for another.
• Caching of requested information - improves client and server interactive performances.
  

Server Types and Characteristics:

• Servers may exhibit many different characteristics and function differently based on their design.
• Many combinations of the following server types may exist:
  • Iterative Servers vs. Concurrent Servers.
  • Connectionless Servers vs. Connection-Oriented Servers.
  • Multi-protocol Servers (UDP, TCP)
  • Multi-service Servers (inetd, HTTP, FTP)

Program Interface to Protocols:

• Routines the operating system supplies, define the interface between the applications and protocol software (Application Program Interface - API).
• The interface between TCP/IP and applications that use it, is loosely specified to allow operation in a multi-vendor environment (only suggests the required functionality)
• 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.
• Two primary TCP/IP interfaces exist:
  • BSD (Berkeley) UNIX Sockets Interface.
    • Uses 'sockets' as it's connection abstraction.
  • AT&T System V UNIX Transport Layer Interface (TLI).
    • Uses 'streams' as it's connection abstraction.

TCP/IP Recommended API Functionality:

• TCP/IP does not define an API, however the standards do suggest the functionality needed:
  • Allocate local resources for communication.
  • Specify local and remote communication endpoints.
  • Initiate a connection (client side).
  • Wait for an incoming connection (server side).
  • Send or receive data.
  • Generate and handle incoming urgent data.
  • Terminate a connection gracefully.
  • Handle connection termination from the remote site.
  • Abort communication.
  • Handle error conditions.
  • Release local resources when communication is finished.

Interfacing with TCP/IP:

• The conceptual interface defined by TCP/IP standards does not specify data representations or programming details
• However, it does provide an example of one possible interface an operating system can offer to applications using TCP/IP.
• The socket interface ranks as the defacto standard for accessing underlying communication services.

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.

Control passes from:

• A process acquires privileges when it passes through the system call interface.
  

System I/O Calls:

• Using conventional I/O calls to also handle network communication keeps functionality simple and uniform (Function Overloading).
• For example, the open I/O call returns a:
  • File descriptor for a file.
  • Socket descriptor for a socket.

All work was written, produced, and is copyrighted by Daniel Z. Tabor Jr.
Page created by Daniel Z. Tabor Jr. Copyright ©1995 Illusion Industries Inc.