Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
87 views

2161CS136 Distributed Systems: Unit II Process and Distributed Objects Lecture No.10 Interprocess Communication

This document discusses interprocess communication and provides details about UDP datagram communication. It describes how sockets provide an endpoint for communication between processes and how processes use sockets bound to ports and IP addresses to send and receive messages. It explains that UDP provides an unreliable datagram-based communication with the possibility of message loss or reordering and outlines some of the issues involved in datagram communication like message size and timeouts.

Uploaded by

amrita cse
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
87 views

2161CS136 Distributed Systems: Unit II Process and Distributed Objects Lecture No.10 Interprocess Communication

This document discusses interprocess communication and provides details about UDP datagram communication. It describes how sockets provide an endpoint for communication between processes and how processes use sockets bound to ports and IP addresses to send and receive messages. It explains that UDP provides an unreliable datagram-based communication with the possibility of message loss or reordering and outlines some of the issues involved in datagram communication like message size and timeouts.

Uploaded by

amrita cse
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

Department of

Computer Science and Engineering

2161CS136
DISTRIBUTED SYSTEMS
Unit II Process and Distributed Objects
Lecture No.10 Interprocess Communication

Academic Year : 2021-21(WS)


Faculty Name : Dr.M.Gokuldhev

School of Computing
Vel Tech Rangarajan Dr. Sagunthala R&D Institute of
Science and Technology
Interprocess communication
Learning objective:

This chapter is concerned with the characteristics of protocols for


communication between processes in a distributed system – that is,
interprocess communication.
• Interprocess communication in the Internet
provides both datagram and stream
communication.
Introduction
• The application program interface to UDP provides a message passing
abstraction – the simplest form of interprocess communication. This
enables a sending process to transmit a single message to a receiving
process. The independent packets containing.

• These messages are called datagrams. In the Java and UNIX APIs, the
sender specifies the destination using a socket – an indirect reference to a
particular port used by the destination process at a destination computer.
• The application program interface to TCP provides the abstraction of a two-
way stream between pairs of processes.

• Streams provide a building block for producer-consumer communication. A


producer and a consumer form a pair of processes in which the role of the
first is to produce data items and the role of the second is to consume them.

• The data items sent by the producer to the consumer are queued on arrival at
the receiving host until the consumer is ready to receive them.

• The consumer must wait when no data items are available.

• The producer must wait if the storage used to hold the queued data items is
exhausted.
The API for the Internet protocols
• In this section, we discuss the general characteristics of interprocess
communication and then discuss the Internet protocols as an example,
explaining how programmers can use them, either by means of UDP
messages or through TCP streams.
The characteristics of interprocess
communication
• Message passing between a pair of processes can be supported by two
message communication operations, send and receive, defined in terms of
destinations and messages.

– Synchronous and asynchronous communication.


– Message destinations.
– Reliability.
– Ordering.
Synchronous and asynchronous

communication
In the synchronous form of communication, the sending and receiving processes
synchronize atevery message. In this case, both send and receive are blocking
operations.

• Whenever a send is issued the sending process (or thread) is blocked until the
corresponding receive is issued.

• Whenever a receive is issued by a process (or thread), it blocks until a message arrives.
• In the asynchronous form of communication, the use of the send operation is
nonblocking in that the sending process is allowed to proceed as soon as the message
has been copied to a local buffer, and the transmission of the message proceeds in
parallel with the sending process.
• The receive operation can have blocking and non-blocking variants.

• In the non-blocking variant, the receiving process proceeds with its program after
issuing a receive operation, which provides a buffer to be filled in the background,but it
must separately receive notification that its buffer has been filled, by polling or
interrupt.
Message destinations
• Messages are sent to (Internet address, local port) pairs.

• A local port is a message destination within a computer, specified as an


integer. A port has exactly one receiver (multicast ports are an exception, see
Section 4.5.1) but can have many senders.

• Processes may use multiple ports to receive messages. Any process that
knows the number of a port can send a message to it.

• Servers generally publicize their port numbers for use by clients.

• If the client uses a fixed Internet address to refer to a service, then that
service must always run on the same computer for its address to remain
valid.
Reliability
• Reliability defines reliable communication in terms of validity and integrity.

• As far as the validity property is concerned, a point-to-point message service


can be described as reliable if messages are guaranteed to be delivered
despite a ‘reasonable’ number of packets being dropped or lost.

• In contrast, a point-to-point message service can be described as unreliable if


messages are not guaranteed to be delivered in the face of even a single
packet dropped or lost.

• For integrity, messages must arrive uncorrupted and without duplication.


Ordering
• Some applications require that messages be delivered in sender order – that
is, the order in which they were transmitted by the sender. The delivery of
messages out of sender order is regarded as a failure by such applications
Conclusion
Learning outcome :
•Intro to Interprocess communication.
•Characteristics of Interprocess Communication.
Any queries??

• If not, Thank you and stay safe.


Department of
Computer Science and Engineering

2161CS136
DISTRIBUTED SYSTEMS
Unit II Process and Distributed Objects
Lecture No.11 Sockets and UDP

Academic Year : 2021-21(WS)


Faculty Name : Dr.M.Gokuldhev

School of Computing
Vel Tech Rangarajan Dr. Sagunthala R&D Institute of
Science and Technology
Socket
• Both forms of communication (UDP and TCP) use the socket abstraction,
which provides an endpoint for communication between processes.

• Sockets originate from BSD UNIX but are also present in most other
versions of UNIX, including Linux as well as Windows and the Macintosh
OS.

• Interprocess communication consists of transmitting a message between a


socket in one process and a socket in another process.
Socket (Cont.)
• For a process to receive messages, its socket must be bound to a local port
and one of the Internet addresses of the computer on which it runs.

• Messages sent to a particular Internet address and port number can be


received only by a process whose socket is associated with that Internet
address and port number.

• Processes may use the same socket for sending and receiving messages.

• Each computerhas a large number (216 ) of possible port numbers for use by
local processes for receiving messages.

• Any process may make use of multiple ports to receive messages but a
process cannot share ports with other processes on the same computer.
However, any number of processes may send messages to the same port.
Each socket is associated with a particular protocol – either UDP or TCP.
Java API for Internet addresses
• As the IP packets underlying UDP and TCP are sent to Internet addresses,
Java provides a class, InetAddress, that represents Internet addresses.

• Users of this class refer to computers by Domain Name System (DNS)


hostnames.

• For example, instances of InetAddress that contain Internet addresses can be


created by calling a static method of InetAddress, giving a DNS hostname as
the argument.

• For example, to get an object representing the Internet address of the host
whose DNS name is bruno.dcs.qmul.ac.uk, use:

InetAddress aComputer = InetAddress.getByName("bruno.dcs.qmul.ac.uk");


Java API for Internet addresses
• Note that the user of the class does not need to state the explicit value of an
Internet address.

• In fact, the class encapsulates the details of the representation of Internet


addresses.
UDP datagram communication
• A datagram sent by UDP is transmitted from a sending process to a receiving
process without acknowledgement or retries. If a failure occurs, the message
may not arrive.

• A datagram is transmitted between processes when one process sends it and


another receives it.

• To send or receive messages a process must first create a socket bound to an


Internet address of the local host and a local port.

• A server will bind its socket to a server port – one that it makes known to
clients so that they can send messages to it.

• A client binds its socket to any free local port. The receive method returns the
Internet address and port of the sender, in addition to the message, allowing the
recipient to send a reply.
Issues relating to datagram
communication
• Message size
- The receiving process needs to specify an array of bytes of a particular size
in which to receive a message.
- If the message is too big for the array, it is truncated on arrival.
• Blocking

- Sockets normally provide non-blocking sends and blocking receives


fordatagram communication.

• Timeouts:
- The receive that blocks forever is suitable for use by a server that is waiting
to receive requests from its clients.

• Receive from any


Failure model for UDP datagrams
UDP datagrams suffer from the following failures:

- Omission failures: Messages may be dropped occasionally, either


because of a checksum error or because no buffer space is available at the
source or destination.
- To simplify the discussion, we regard send-omission and receive-
omission failures as omission failures in the communication channel.

•Ordering: Messages can sometimes be delivered out of sender order.


Use of UDP
• For some applications, it is acceptable to use a service that is liable to
occasional omission failures. For example, the Domain Name System, which
looks up DNS names in the Internet, is implemented over UDP. Voice over IP
(VOIP) also runs over UDP.
• UDP datagrams are sometimes an attractive choice because they do not suffer
from the overheads associated with guaranteed message delivery.

There are three main sources of overhead:


• the need to store state information at the source and destination;
• the transmission of extra messages;
• latency for the sender.
Any queries??

• If not thank you,stay safe and hopeful.

You might also like