MODULE 3

CLIENT SERVICES
 Client services in a client-server architecture are
the user-facing, front-end applications that initiate
requests for data, processing, or resources from a
centralized server.
 Key services include user interface presentation,
input handling, request formatting (e.g., HTTP), and
displaying results to users via browsers, apps, or
terminals.
In client/server computing, a client sends a request to a
server over a network. The server processes the
request, performs the necessary actions (such as
retrieving data or run
Key Client Services & Responsibilities:

 User Interface (UI) Management: Displaying information and rendering

content.

 User Interaction Logic: Handling user inputs, form validation, and formatting
requests.

 Request Initiation: Sending requests (e.g., GET/POST via HTTP) to the

server.

 Data Presentation: Receiving and displaying processed data or results.

 Local Processing: Executing minimal tasks locally to improve

responsiveness before connecting to the server.

 Client-Side Caching: Storing frequently accessed data locally to reduce

network latency.
Common Types of Client-Side Components

 Web Browsers: Chrome, Firefox, Safari.

 Email Clients: Outlook, Gmail.

 Desktop/Mobile Applications: Various, social media apps.

 Service Clients: Software modules in Java/other languages that make API

calls.

IMPORTANT CLIENT SERVICES

 Inter process communication

 Remote services
 Window servies
 Dynamic data exchange
 Common object request broker architecture(CORBA)
 Print/fax services
 Database services

INTER PROCESS COMMUNICATION

Inter-Process Communication or IPC is a mechanism that allows processes to

communicate and share data with each other while they are running. Since each
process has its own memory space, IPC provides controlled methods for exchanging
information and coordinating actions. It helps processes work together efficiently and
safely in an operating system.
 It helps processes synchronize their activities, share information and
avoid conflicts while accessing shared resources.

 There are two method of IPC, shared memory and message passing.
An operating system can implement both methods of communication.

Example: A simple example of IPC is a bank ATM system, where one process
reads the card and PIN, another checks the account balance, and a third dispenses
cash. These processes communicate and coordinate to complete the transaction
correctly.

Shared Memory
Communication between processes using shared memory requires processes
to share some variable and it completely depends on how the programmer will
implement it. Processes can use shared memory for extracting information as a
record from another process as well as for delivering any specific information to
other processes.
  In the shared memory model, a common memory space is allocated by
the kernel.
 Process A writes data into the shared memory region (Step 1).
 Process B can then directly read this data from the same shared memory
region (Step 2).
 Since both processes access the same memory segment, this method is
fast but requires synchronization mechanisms (like semaphores) to avoid
conflicts when multiple processes read/write simultaneously.

 Example: Multiple people can edit the document at the same time in

Advantage of Shared Memory

Memory communication is faster on the shared memory model as compared to the

message passing model on the same machine.

Disadvantages of Shared Memory

Some of the disadvantages of shared memory model are as follows –

 All the processes that use the shared memory model need to make sure that
they are not writing to the same memory location.
 Shared memory model may create problems such as synchronization and
memory protection that need to be addressed.

Message Passing
Message Passing is a method where processes communicate by sending
and receiving messages to exchange data. One process sends a message and the
other process receives it, allowing them to share information. Message Passing
can be achieved through different methods like Sockets, Message Queues or
Pipes.

 In the message passing model, processes exchange information by

sending and receiving messages through the kernel.
 Process A sends a message to the kernel (Step 1).
 The kernel then delivers the message to Process B (Step 2).
 Here, processes do not share memory directly. Instead, communication
happens via system calls (send(), recv(), or similar).
 This method is simpler and safer than shared memory because there’s
no risk of overwriting shared data, but it incurs more overhead due to
kernel involvement.
 Example: Multiple people send updates to a group chat, but each
message goes through the server before others see it, like processes
sending messages instead of directly sharing memory

Advantage of Messaging Passing

The message passing model is much easier to implement than the shared memory
model.
Disadvantage of Messaging Passing
The message passing model has slower communication than the shared memory
model because the connection setup takes time.

some common classical IPC problem are:

Dining Philosophers Problem

This problem illustrates deadlock and starvation. The Dining Philosophers

Problem involves five philosophers sitting around a table, each needing two forks
(shared resources) to eat. If all philosophers pick up one fork at the same time,
none can eat, resulting in deadlock.
Solution
 Use semaphores or monitors to control access to forks.
 Allow only one philosopher to pick forks at a time or limit eating to four
philosophers.
 Enforce an order of picking forks to avoid circular wait.
 Prevents deadlock and starvation.

Producer–Consumer Problem

This problem deals with synchronization and buffer management. The Producer–
Consumer Problem describes producers generating data and placing it in a
shared buffer, while consumers remove data from it. The main challenge is
preventing producers from adding data to a full buffer and consumers from
removing data from an empty buffer.
Solution
 Use mutex to ensure mutual exclusion on the shared buffer.
 Use counting semaphores to track empty and full buffer slots.
 Producer waits if buffer is full; consumer waits if buffer is empty.

OTHER IPC METHODS ARE:

Pipes
Pipes are unidirectional communication channels used for inter-process
communication between two related processes. One process writes data into the
pipe, and the other reads it in a sequential manner. Pipes are simple and efficient
for small data transfers on the same system.
 Unidirectional communication
 Used between related processes
 Simple and easy to use
 Types: Anonymous pipes and Named pipes (FIFOs)
Sockets
Sockets are communication endpoints that allow processes to communicate either
on the same machine or over a network. They are commonly used in client–server
systems. Sockets support different protocols such as TCP for reliable
communication and UDP for faster communication.
 Supports network communication
 Works between different systems
 Uses TCP and UDP protocols
 Common in client–server applications
Semaphores
Semaphores are synchronization tools used in IPC to control access to shared
resources. They ensure that only one process can enter a critical section at a time,
preventing race conditions and data corruption. Semaphores are often used along
with shared memory.
 Used for synchronization
 Prevents race conditions
 Controls access to shared resources
 Ensures mutual exclusion
Message Queues
Message Queues allow processes to communicate by sending messages to a
queue managed by the operating system kernel. Messages remain in the queue
until the receiving process retrieves them. This method supports asynchronous
communication and provides reliable message delivery.
 Kernel-managed message storage
 Asynchronous communication
 Processes need not run simultaneously
 Reliable but slower than shared memory
Other methods include Memory-Mapped Files, Signals, Futures/Promises, and
middleware-based message passing. These methods are used as per the
communication requirements, system design, and process locations.

REMOTE PROCEDURE CALL

A Remote Procedure Call (RPC) is a communication protocol that enables a

program to request a service or execute a procedure on a remote server as though
it were a local function call. Remote Procedure Call (RPC) is a
communication technique that allows a program on a client machine to
execute a procedure on a remote server as if it were a local function call.
This mechanism is fundamental to building distributed client-server
applications by abstracting the complexities of network communication
from the developer.A Remote Procedure Call (RPC) is a software
communication protocol that one program uses to request a service from
another program located on a different computer and network, without
having to understand the network's details. Specifically, RPC is used to
call other processes on remote systems as if the process were a local
system. A procedure call is also sometimes known as a function call or
a subroutine call.

RPC acts like a low-level transport protocol for carrying data packets
between communicating programs. It does this using a client-
server model. The requesting program is called a client, while the
service-providing program is called the server. Like a local procedure
call, an RPC is a synchronous operation requiring the requesting
program to be suspended until the results of the remote procedure are
returned. However, the use of lightweight processes or threads that
share the same address space enables multiple RPCs to be performed
concurrently.

Interface definition language (IDL) -- the specification language used to

describe a software component's application programming interface
(API) -- is commonly used in Remote Procedure Call software. In this
case, IDL provides a bridge between the machines at either end of the
link that might be using different operating systems (OSes) and
computer languages. This means that RPC is usable on operating
systems such as Windows, Unix and macOS.

RPC WORKING

RPC is commonly used to build and interact with distributed systems. RPC enables
a program to call a subroutine on a different computer without it knowing it's
remote. Even though RPC acts like a transport protocol, it's actually an inter-
process communications procedure.
When a program statement or instruction that uses the RPC framework is compiled
into an executable program, a stub is included. A stub is a piece of code that's used
to convert parameters that are passed between a client and a server. The stub acts
as a representative of the remote procedure code. When the program is run and the
procedure call is issued, the stub receives the request and forwards it to a
client runtime program on the local computer. The first time the client stub is
invoked, it contacts a name server to determine the transport address where the
server resides.

The client runtime program knows how to address the remote computer and server
application and sends the message across the network that requests the remote
procedure. Similarly, the server includes a runtime program and stub that interfaces
with the remote procedure itself. Response-request protocols are returned the same
way.

When a remote procedure call is invoked, the calling environment is first

suspended. Procedure parameters are then transferred across the network to the
device where the procedure is planned to execute. Following this, the procedure
begins executing in that environment.

When the procedure is complete, data is transferred back to the calling

environment, where program execution continues -- as if it had returned from a
normal procedure call.

The following steps occur during an RPC:

1. The client calls the client stub. The call is a local procedure call with
parameters pushed onto the stack in the usual way.

2. The client stub packs the procedure parameters into a message and
makes a system call to send the message. The packing of the procedure
parameters is called marshaling.

3. The client's local OS sends the message from the client device to the
remote server device.
 4. The server OS's transport layer passes the incoming packets to the server
stub.

5. The server stub unpacks the parameters -- called unmarshaling -- from

the message.

6. When the server procedure is finished, it returns to the server stub,

marshaling the return values in a message. The server stub then sends the
message to the transport layer.

7. The transport layer sends the message to the client transport layer, which
then returns the message to the client stub.

8. The client stub unmarshalls the return parameters and the execution
returns to the caller.

RPC can also be modified to work effectively in other environments, such as in

microservices.

 The client invokes a function on the server located in a different address

space.
 The RPC framework handles the details of network communication,
serialization, and response management.
 This makes remote communication transparent to developers,
promoting cleaner and more modular distributed applications

RPC Architecture
RPC follows a client-server model, where the client requests execution of a
remote procedure and the server responds.

1. Client and Server Components

 Client: Initiates the request using a local stub.

 Server: Hosts the actual implementation of the remote procedure.

2. Stubs

 Client Stub: Packs (marshals) arguments, sends request, and receives

results.
  Server Stub: Unpacks (unmarshals) arguments, executes the
procedure, and sends results back.

3. Marshalling and Unmarshalling

 Marshalling: Converts data/arguments into transmittable byte streams.

 Unmarshalling: Converts byte streams back into usable data.

4. Communication Layer

 Uses transport protocols (TCP/UDP).

 Manages message routing, buffering, and error handling.

5. RPC Framework

 IDL (Interface Definition Language): Defines procedures,

parameters, and return types independent of programming language.
 RPC Protocol: Specifies communication rules, request-response
format, and error handling.

6. Error Handling and Fault Tolerance

 Timeouts and Retries: To handle failures and delays.

 Exception Handling: Reports errors to clients.

7. Security

 Authentication/Authorization: Ensures only valid clients can access

services.
 Encryption: Protects data during transmission (e.g., SSL/TLS)

Types of RPC

1. Synchronous RPC

 Client waits for server response.

 Simple design but blocking in nature.
 Used when immediate response is required.
2. Asynchronous RPC

 Client sends request and continues execution without waiting.

 More complex but improves responsiveness.
 Used in concurrent applications.

3. One-Way RPC

 Client sends request without expecting any response.

 "Fire-and-forget" style.
 Used in logging or notification services.

4. Callback RPC

 Server invokes a client-provided callback after processing.

 Useful for long-running operations.

5. Batch RPC

 Multiple requests are bundled into one batch.

 Reduces network round trips and overhead.

Advantages of Using RPC

 Abstraction: Hides the complexity of network communication, allowing

developers to focus on business logic.

 Simplicity: Remote calls look like local function calls to the programmer.

 Interoperability: Modern RPC frameworks (like gRPC) support

communication between systems written in different programming languages
and running on different platforms.

 Efficiency: Can be more efficient than other communication methods (like

text-based REST APIs) due to lightweight protocols and binary serialization.

Disadvantages of Using RPC

  Vulnerability to Failure: RPC relies heavily on network connectivity and the
availability of the remote machine, making it more vulnerable to failures than
local calls.

 Latency: Network communication inherently adds latency, making remote

calls slower than local ones.

 Lack of Standardization: There is no single universal standard for RPC,

leading to various, often incompatible, implementations.

 Parameter Limitations: Traditionally only supports passing parameters by

value, not by reference or pointer, limiting data transfer complexity.

OBJECT LINKING AND EMBEDDING

Object Linking and Embedding (OLE) functions within a client-server
architecture by allowing a client application (container) to use objects provided by
a server application (source). This enables the creation of compound
documents that seamlessly integrate data from multiple sources within a single
application. Object Linking and Embedding (OLE) might sound a bit technical, but it’s
actually a clever Microsoft technology that simplifies how programs work together. At
its core, OLE enables you to integrate content like text, images, charts, and even
spreadsheets from different applications into a single document

The Client-Server Model in OLE

In the OLE framework, the roles are defined as follows:
 Client Application (Container): This is the application that hosts the OLE
object (e.g., a Microsoft Word document that contains an Excel chart). It uses
OLE control to manage and display the integrated data.

 Server Application (Source): This is the original application used to create

the object (e.g., Microsoft Excel). It provides the data and the functionality to
edit the object, even when the object is viewed within the client application.
 Communication between these applications is managed by system libraries
built on Microsoft's Component Object Model (COM), which provides the
underlying infrastructure for inter-process communication.

Linking vs. Embedding in a Client-Server Context

The key difference lies in where the object's data is stored and how it is accessed:
Feature Embedded Object Linked Object

Data Storage The object's data is a copy The data is stored in the original source file. The
stored within the client client document only stores a pointer/reference to
(container) document. the source file.

Updates Changes to the original source Changes to the source file automatically reflect in
file do not affect the embedded all documents that link to it.
object. The object is a static
copy.

Dependencies No access to the source file is The client needs continuous access to the
needed after embedding. This original source file and the source application.
aids portability. Moving or renaming the source file breaks the
link.

File Size Increases the size of the client Results in a smaller client document size.
document.

How It Works
1. Integration: A user inserts an object from a server application into a client
application (e.g., an Excel chart into a Word document).

2. Activation: When the user wants to edit the object (typically by double-
clicking), the client application activates the server application, either
launching it separately or "in-place" within the client's interface.

3. Communication: The client and server applications communicate via COM

interfaces, allowing the user to utilize the server's tools and functionality while
remaining in the context of the client document.

4. Data Exchange:

1. For linked objects, the client retrieves the updated data from the
source file.

2. For embedded objects, the data edited is the local copy within the
client document itself.

This client-server model allows for robust application integration, enabling a Visual
Basic application, for instance, to leverage the complex capabilities of an Excel
spreadsheet without having to re-implement that functionality.
CORBA

The Common Object Request Broker Architecture (CORBA) is a standard defined by

the Object Management Group (OMG) that enables software components written in
multiple computer languages and running on multiple computers to work together.
Common Object Request Broker Architecture (CORBA) could be a
specification of a regular design for middleware. It is a client-server software
development model.
Using a CORBA implementation, a shopper will transparently invoke a way on a
server object, which may air a similar machine or across a network. The
middleware takes the decision, associated is to blame for finding an object that
will implement the request, passing it the parameters, invoking its methodology,
and returning the results of the invocation. The shopper doesn't need to remember
wherever the item is found, its programming language, its software package or
the other aspects that don't seem to be a part of the associated object’s interface.

CORBA Reference Model:

The CORBA reference model known as Object Management design (OMA) is
shown below figure. The OMA is itself a specification (actually, a group of
connected specifications) that defines a broad variety of services for building
distributed client-server applications. Several services one may expect to search
out in a very middleware product like CORBA (e.g., naming, dealings, and
asynchronous event management services) are literally fixed as services within
the OMA
 CORBA Reference
Model

Different parts communicate victimization ORB. ORB is additionally referred to

as the item bus. An associate example of the application interface is a distributed
document facility. In a very domain interface, it will have domain dependent
services, for instance, producing domain.
Object interface has some domain freelance services:
1. Naming Service:
Naming service is additionally known as a white page service.
Victimization naming service server-name will be searched, and its
location or address pointed out.

2. Trading Service:
Commercialism service is additionally known as a yellow page service.
Victimization commercialism service a selected service will be
searched. This is often corresponding to looking out a service like an
automobile store in a very yellow page directory.
The Broker pattern is particularly useful in helping you follow these design
principles:
 Divide and conquer. The remote objects can be independently
designed.
 Increase reusability. It is typically possible to design the remote
objects so that other systems can use them too.
 Increase reuse. You may be able to reuse remote objects that others
have created.
 Design for flexibility. The broker objects can be updated as required,
or you can redirect the proxy to communicate with a different remote
object.
 Design for portability. You can write clients for new platforms while
still accessing brokers and remote objects on other platforms.
 Design defensively. You can provide careful assertion checking in the
remote objects.