Unit4.1 Communication

Communication
• 4.1 FUNDAMENTALS
• 4.1.1 Layered Protocols
• Lower-Level Protocols
• Higher- Level Protocols
• Middleware Protocols transport protocols
• 4.1.2 Types of Communication

• 4.2 REMOTE PROCEDURE CALL
• 4.3 MESSAGE-ORIENTED COMMUNICATION
• 4.5 MULTICAST COMMUNICATION
2/21/2022 BCA_DS_4.1_DN_NC(dineupane8@gmail.com) 1
Inter process communication
• Process can be independent process or dependent process
• Independent process are not affected by others process and it also do
not affect other process running in the system
• Cooperating /dependent process can affect or be affected by other
process executing in the system
• A cooperating process share data with other process
• Interprocess communication is required in cooperating process
• Interprocess communication (IPC) is a set of programming interface
that allows a programmer to coordinate processes that can run
concurrently in an operating system
Inter process communication
• Two fundamental models for interprocess communication
• Shared memory
• Message passing
• In shared memory a region of memory is shared by cooperating process is
established.
• Process then exchange message (communicate) by reading and writing data to
the shared region.
• In a uniprocessor system, interprocess communication assumes the existence of
shared memory
• where as in a distributed system, there is no shared memory.

• All communication in a distributed system is based on a message passing
between the cooperating process.
• A) Message passing
• B) Shared memory
Layered protocols
Lower level protocols
• Physical layer is transmitting 0 and 1
• Representation of bits→bits must be encoded into signals for
transmission. How 0 and 1 are changed into signals.
• Rate of data transmission(no of bits per second)
• Synchronization→sender and receiver are synchronized at bit
level
Lower layer
• Data link layer computes checksum
• Forms frames from the packet received from the network layer and gives it to the
physical layer.
• Error control
• Access control(which device has the access to the communication link when two or more
device are connected to the same link
• Flow control (avoid fast transmissing at sender and late buffering at receiver to prevent
traffic jam)
Network layer is a part of internet protocol suite. IP Packet exchanging

• Routing i.e choose the best path
Transport protocols
• Transport protocols
• Accept data from above layer, splits up it into smaller units,
• Segmentation and reassembling of the message
• Connection control (TCP/UDP)
• Tcp → provide acknowledgement , can be slow , reliable , ensure delivery
• Udp → faster delivery but no gurantee
High level protocol
• Session layer
• Establish active communication session between them
• Token management and synchronization(prevents two communicating parties
for accessing same critical section)
• Presentation layer
• Provide interoperatibility between encoding method as different computers
used different encoding method.
• Encryption and decryption
• Compression
High level protocols
• Application layer
• Identifying partners for communication:
• Determining the availability of network resources
• E.g Email,
• Protocols are HTTP, FTP, DNS, Telnet
Remote procedure call
• Remote Procedure Call is a software communication protocol that
one program can use to request a service from a program located in
another computer on a network without having to understand the
network's details
• RPC is used to call other processes on the remote systems like a local
system. A procedure call is also sometimes known as a function call or
a subroutine call.
• RPC uses the client-server model. The requesting program is a client,
and the service-providing program is the server
• Client – program that is waiting for service
• Client stub
• It is responsible for the following two tasks
• On receipt of the call request from the client, it packs the specification of the
target procedure into a message.
• Asks the local RPC runtime to send it to the server
• On receipt of the result of procedure execution, it unpacks the result and
passes it to the client
• RPC runtime
• It handles the transmission of message across the network between the client
and the server machine.
• It is responsible for
• Retransmission
• Acknowledgement
• Routing
• Encryption
• Server stub
• It is responsible for the following two tasks
• On receipt of call request message , from the local RPC runtime , it unpacks
it and makes perfectly normal call to invoke the appropriate procedure in the
server.
• On receipt of the result of the procedure, from the server, it packs the result
into a message and asks the local RPC runtime to send it to the client stub
• Server- program that is providing service/implementation detail

(here)
Steps of remote procedure call
1. The client procedure calls the client stub in the normal way.
2. The client stub builds a message and calls the local operating system.
3. The client's OS sends the message to the remote OS.
4. The remote OS gives the message to the server stub.
5. The server stub unpacks the parameters and calls the server.
6. The server does the work and returns the result to the stub.
7. The server stub packs it in a message and calls its local OS.
8. The server's OS sends the message to the client's OS.
9. The client's OS gives the message to the client stub.
10. The stub unpacks the result and returns to the client.
RPC
Synchronous and asynchronous RPC
• In conventional procedure calls, when a client calls a remote
procedure, the client will block until a reply is returned.
• This strict request-reply behavior is unnecessary when there is no
result to return, and only leads to blocking the client while it could
have proceeded and have done useful work just after requesting the
remote procedure to be called.
• To support such situations, RPC systems may provide facilities for
what are called asynchronous RPCs, by which a client immediately
continues after issuing the RPC request. With asynchronous RPCs, the
server immediately sends a reply back to the client the moment the
RPC request is received, after which it calls the requested procedure.
The reply acts as an acknowledgment to the client that the server is
going to process the RPC. The client will continue without further
blocking as soon as it has received the server's acknowledgment.
• Asynchronous RPCs can also be useful when a reply will be returned
but the client is not prepared to wait for it and do nothing in the
meantime. For example, a client may want to prefetch the network
addresses of a set of hosts that it expects to contact soon. While a
naming service is collecting those addresses, the client may want to
do other things. In such cases, it makes sense to organize the
communication between the client and server through two
asynchronous RPCs,
Types of Communication in distributed
system
• Persistent vs transient communication
• Synchronous vs asynchronous communication
Persistent vs transient communication
• Persistent communication
• A message sent is stored by the communication middleware until it is delivered to
the receiver
• “Receiver” need not be in operation – communications system buffers message as
required until delivery can occur.
• No need for time coupling between the sender and the receiver
• Transient communication
• A message sent is stored by the communication middleware only as long as both the
receiver and the sender are executing
• Message only stored as long as “sender” & “receiver” are executing.
• Time coupling between the sender and the receiver
Synchronous vs asynchronous communication
• Asynchronous communication — The sender keeps on executing
after sending a message
• → The message should be stored by the middleware
• Synchronous communication — The sender blocks execution after
sending a message and waits for response –
• until the middleware acknowledges transmission,
• or, until the receiver acknowledges the reception,
• or, until the receiver has completed processing the request
→ Some form of coupling in control between the sender and the receiver
Communication with a middleware layer
Persistent asynchronous and Persistent
synchronous communication
Persistent asynchronous
• Message are persistently stored in local host buffer or an
intermediate communication server
• E.g mail
• Persistent synchronous
• Message can be persistently stored only receiving end
• For weaker synchronous, it is not necessary for receiving application
to be executing(at this situations some accepted message is send to
sender)
Transient asynchronous vs transient
Message oriented transient communication
• Berkeley Socket Primitives, and Message-Passing Interface (MPI) are
examples of message-oriented transient communication
• These systems do not use on-disk queues for message storing.
Berkeley socket
• A socket is a communication end point to which an application can
write data that are to be sent out over the underlying network, and
from which incoming data can be read .
• An endpoint usually includes a port number and an IP address.
• A server socket - It awaits a request from a client
1.A client socket - It establishes communication between client and
server.
• The client has to know two things about the server:
1.The server’s IP address.
2.The port number.
• The server constructs a ServerSocket object to specify the port
number on which our conversation will occur. Exception handling
methods are in use whenever an I/O error occurs.
Berkeley socket
• Sockets were deemed insufficient for two reasons.
• First, they were at the wrong level of abstraction by supporting only simple
send and receive primitives.
• Second, sockets had been designed to communicate across networks using
general-purpose protocol stacks such as TCP/IP.
• They were not considered suitable for the proprietary protocols
developed for high-speed interconnection networks, such as those used in
high-performance server clusters.
• Those protocols required an 'interface that could handle more advanced
features, such as different forms of buffering and synchronization.
• led to the definition of a standard for message passing, simply called
the Message-Passing Interface or MPI.
Message passing interface
Message passing interface(MPI)
• Berkeley Socket Primitives, and Message-Passing Interface (MPI) are
examples of message-oriented transient communication.
• These systems do not use on-disk queues for message storing.
• Below, we map the MPI primitive functions to one of the above types.
• MPI bsend simply appends the outgoing message to the local send
buffer, and then keeps running. Thus, it is transient asynchronous
communication.
• MPI send sends a message and waits until copied to the remote buffer.
This is similar to delivery-based transient synchronous communication
• MPI ssend waits until receipt start serves as receipt based transient
• MPI sendrecv waits for a reply, and serves as reply based transient
synchronous communication respectively.
• Hence, these constructs map very well to different communication types .
• MPI allows you to choose what kinds of combination of Sync
communication you wish to use.
• It is a much richer communication system where the programmer can
choose what form of communication to use from a spectrum of choices.
• The operation MPLrecv is called to receive a message; it blocks the caller
until a message arrives. (synchronous variant)
• There is also an asynchronous variant, called MPLirecv, by which a receiver
indicates that is prepared to accept a message.
• With MPI_isend, a sender passes a pointer to the message after which the
MPI runtime system takes care of communication. The sender immediately
continues. (asynchronous varient)
• with MPLissend a sender also passes only a pointer to the :MPI runtime
system. When the runtime system indicates it has processed the message,
the sender is then guaranteed that the receiver has accepted the message
and is now working on it(synchronous varient)
Message oriented persistent communication
Message oriented persistent communication
• Message-queuing systems provide extensive support for persistent
asynchronous communication.
• The essence of these systems is that they offer intermediate-term
storage capacity for messages,
• without requiring either the sender or receiver to be active during
message transmission
• An important difference with Berkeley sockets and MPI is that
message-queuing systems are typically targeted to support message
transfers that are allowed to take minutes instead of seconds or
milliseconds.
• The basic idea behind a message-queuing system is that applications
communicate by inserting messages in specific queues.
• These messages are forwarded over a series of communication servers
and are eventually delivered to the destination, even if it was down when
the message was sent
• In practice, most communication servers are directly connected to each
other.
• In other words, a message is generally transferred directly to a destination
server.
• In principle, each application has its own private queue to which other
applications can send messages
• A queue can be read only by its associated application, but it is also
possible for multiple applications to share a single queue
• An important aspect of message-queuing systems is that a sender is
generally given only the guarantees that its message will eventually
be inserted in the recipient's queue.
• No guarantees are given about when, or even if the message will
actually be read, which is completely determined by the behavior of
the recipient.
• These semantics permit communication loosely-coupled in time
• There is thus no need for the receiver to be executing when a
message is being sent to its queue
• Likewise, there is no need for the sender to be executing at the
moment its message is picked up by the receiver.
• The sender and receiver can execute completely independently of
each other
• In fact, once a message has been deposited in a queue, it will remain
there until it is removed, irrespective of whether its sender or
receiver is executing. This gives us four combinations with respect to
the execution mode of the sender and receiver as below.
Message queuing model
• In Fig.4-17(a), both the sender and receiver execute during the entire
transmission of a message.
• In.Fig. 4-17(b), only the sender is executing, while the receiver is passive,
that is, in a state in which message delivery is not possible. Nevertheless,
the sender can still send messages.
• The combination of a passive sender and an executing receiver is shown in
Fig. 4-17(c). In this case, the receiver can read messages that were sent to
it, but it is not necessary 'that their respective senders are executing as
well.
• Finally, in Fig. 4-17(d), we see the situation that the system is storing (and
possibly transmitting) messages even while sender and receiver are passive
Queuing architecture
• Queues are managed by queue managers.
• Normally, a queue manager interacts directly with the application that is
sending or receiving a message
• However, there are also special queue managers that operate as routers, or
relays:
• they forward incoming messages to other queue managers.
• Some primitives are
• Put
• Get
• Poll
• Notify
Message queuing primitives
• The put primitive is called by a sender to pass a message to the
underlying system that is to be appended to the specified queue. This
is non blocking.
• The get primitive is a blocking call by which an authorized process can
remove the longest pending message in the specified queue. The
process is blocked only if the queue is empty
• The nonblocking variant is given by the poll primitive. If the queue is
empty, or if a specific message could not be found, the calling process
simply continues.
• Notify →which is automatically invoked whenever a message is put
into the queue.
Multicast communication
Multicast communication
• Multicast is a group communication where a sender sends a data to
multiple receivers or nodes present in a network simultaneously.
• It can be one to many or many to many
• Multicasting works similar to broadcasting, but in multicasting
information is send to the specified members of the network.
• In comparison to broadcasting, multicasting reduces the bandwidth
• For many years, this topic has belonged to the domain of network
protocols, where numerous proposals for network-level and transport-level
solutions have been implemented and evaluated
• A major issue in all solutions was setting up the communication paths for
information dissemination.
• In practice, this involved a huge management effort,
• With the advent of peer-to-peer technology, and notably structured
overlay management, it became easier to set up communication paths.
• As peer-to-peer solutions are typically deployed at the application layer,
various application-level multicasting techniques have been introduced.

Unit4.1 Communication

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit4.1 Communication

Uploaded by

Copyright:

Available Formats

Communication

• 4.1.2 Types of Communication

• where as in a distributed system, there is no shared memory.

Network layer is a part of internet protocol suite. IP Packet exchanging

• Server- program that is providing service/implementation detail

3. The client's OS sends the message to the remote OS.

4. The remote OS gives the message to the server stub.

8. The server's OS sends the message to the client's OS.

9. The client's OS gives the message to the client stub.

You might also like