IPC – unicast and multicast

  L. Liu u Li Li . L L Distributed Computing, M. ng Li

  • Li ei M Mi

  ommunications C Communications

Interprocess Communications

  Operating systems provide facilities for interprocess

  • communications (IPC), such as message queues, i i (IPC) h semaphores, and shared memory. Distributed computing systems make use of these Distributed computing systems make use of these
  • facilities to provide application programming interface which allows IPC to be programmed at a higher level of abstraction. Distributed computing requires information to be
  • exchanged among independent processes. exchanged among independent processes

IPC – unicast and multicast

  z

  In distributed computing, two or more processes engage in IPC in a protocol agreed upon by the processes. A process may be a sender at some processes A process may be a sender at some points during a protocol, a receiver at other points.

  z z

  When communication is from one process to a When communication is from one process to a single other process, the IPC is said to be a unicast.

  When communication is from one process to a group of processes, the IPC is said to be a multicast, f th IPC i id t b l i a topic that we will explore in a later chapter.

Unicast vs. Multicast

  P

  2

  3

  4 ... m m m m

  P P

  1

  1 multicast unicast unicast

Interprocess Communications in Di ib d C i Distributed Computing

  Process 1 Process 2 Process 1 Process 2 data data sender receiver

  Operations provided in an archetypal p p yp Interprocess Communications API

  Receive ( [sender], message storage object) ( [ ], g g j )

  • Connect (sender address, receiver address), for
  • connection-oriented communication. Send ( [receiver], message)
  • Disconnect (connection identifier), for connection- (

  ),

  • oriented communication.

Interprocess Communication in basic HTTP

  S2 S3 S4 Web server a proce ss S1 re que st HTTP S2: re ce ive (re que st) S1: acce pt conne ction ope rations: an ope ration re sponse HTTP C 1: make conne ction S3: se nd (re sponse ) S3: se nd (re sponse ) C 2: se nd (re que st) S3: disconne ct data flow C C 1 C C 2 C 3 C 3 C C 4 C 4: disconne ct C 4 di t C 3: re ce ive (re sponse )

  Web browser

Event Synchronization

  z

  Interprocess communication requires that the two processes synchronize their operations: one side sends, then the other receives until all data has been sent and received.

  z

  Ideally, the send operation starts before the receive d ll h d i b f h i operation commences.

  z

  In practice, the synchronization requires system I ti th h i ti i t support.

Synchronous vs. Asynchronous Communication

  z The IPC operations may provide the synchronization necessary using blocking. A blocking operation issued by a process will block further processing of the process a process will block further processing of the process until the operation is fulfilled. z

  Alternatively, IPC operations may be asynchronous or y p y y nonblocking . An asynchronous operation issued by a process will not block further processing of the process.

  Instead, the process is free to proceed with its processing, Instead the process is free to proceed with its processing and may optionally be notified by the system when the operation is fulfilled.

Synchronous send and receive process 1

  running on host 1 process 2 running on host 2 blocking send starts blocking receive starts an operation b oc g se d sta ts blocking send returns blocking receive ends Synchronous Send and Receive execution flow suspended period a ope at o acknowledgement of data received provided by the IPC facility

  Asynchronous send and synchronous receive Process 1 Process 2 nonblocking send blocking receive starts blocking receive returns suspended period execution flow operation operation Synchronous Receive Asynchronous Send and

Synchronous send and Async. Receive - 1 Process 1

  Process 2 blocking send issued nonblocking receive issued execution flow suspended period transparent acknowledgement provided by the IPC facility

  Synchronous Send and Asynchronous Receive Scenario A

Synchronous send and Async. Receive - 2 Process 1

  Process 2 nonblocking receive issued and returned immediately blocking send issued indefinite blocking execution flow suspended period

  2 Synchronous Send and Asynchronous Receive Scenario B Process 1 Process 2

  Synchronous send and Async. Receive - 3 Process 1 Process 2 blocking send issued process is notified p and returned immediately nonblocking receive issued provided by the IPC facility data transparent acknowledgement of the arrival of suspended period execution flow Asynchronous Receive Synchronous Send and Scenario C

  Asynchronous send and Asynchronous receive Process 1 Process 2 blocking send issued p process is notified and returned immediately nonblocking receive issued data of the arrival of suspended period execution flow Asynchronous Receive Asynchronous Send and Scenario C

  Event diagram Process B Process A Process B request 1 time response 1 interprocess communication request 2 execution flow process blocked response2

  Event diagram for a protocol

Blocking, deadlock, and timeouts

  z Blocking operations issued in the wrong sequence can cause deadlocks . z

  Deadlocks should be avoided. Alternatively, timeout can be used to Deadlocks should be avoided. Alternatively, timeout can be used to detect deadlocks. Process 1 Process 2 from process 2. process 1 blocked pending data receive from process 2 issued i f 2 i d received from process 1 issued from process 1. process 2 blocked pending data

Using threads for asynchronous IPC

  z Wh When using an IPC programming interface, it is important to note i

  IPC i i f i i i whether the operations are synchronous or asynchronous. z

  If only blocking operation is provided for send and/or receive, then it is th the programmer’s responsibility to using child processes or threads if ’ ibilit t i hild th d if asynchronous operations are desired. process main thread main thread other processing main thread continues with thread is blocked th d i bl k d new thread issues a blocking IPC operation thread is unblocked after the operation is fulfilled

Deadlocks and Timeouts

  z Connect and receive operations can result in indefinite blocking z

  For example, a blocking connect request can result in the F l bl ki l i h requesting process to be suspended indefinitely if the connection is unfulfilled or cannot be fulfilled, perhaps as a p p result of a breakdown in the network . z

  It is generally unacceptable for a requesting process to “hang” indefinitely. Indefinite blocking can be avoided by “hang” indefinitely Indefinite blocking can be avoided by using timeout . z

  Indefinite blocking may also be caused by a deadlock g y y

  

Indefinite blocking due to a deadlock

Process 1 Process 2 "receive from process 2" issued; from process 2. process 1 blocked pending data an ope ration "receive from process 1" issued; receive from process 1 issued; from process 1. process 2 blocked pending data proce ss e xe cuting g proce ss blocke d

Data Representation

  z Data transmitted on the network is a binary stream. z

  An interprocess communication system may provide the capability to allow data representation to be imposed on the raw data. z

  Because different computers may have different internal storage format for the same data type, an external representation of data may be necessary. z

  Data marshalling D h lli is the process of (I) flatterning a data structure, i th f (I) fl tt i d t t t

and (ii) converting the data to an external representation.

z

  Some well known external data representation schemes are: Sun XDR S

  XDR ASN.1 (Abstract Syntax Notation)

  XML (Extensible Markup Language)

Data Encoding Protocols level of abstraction

  application specific data encoding language data encoding schemes Sample Standards XML:(Extensible Markup Language) network data encoding standard general data encoding language ASN.1(Abstract Syntax Notation) Sun XDR(External Data Representation)

Sample XML file Sample XML file

  

http://java.sun.com/xml/docs/tutorial/overview/1_xml.html#intro

z

  XML is a text-based markup language that is fast becoming the standard for data interchange on the Web. Web. z XML has syntax analogus to HTML. z

  Unlike HTML, XML tags tell you what the data means , rather than how to display it. rather than how to display it z

  Example: <message>

  <to>you@yourAddress.com</to> <from>me@myAddress.com</from> <subject>XML Is Really Cool</subject> <text> How many ways is XML cool? Let me count the ways... <text> How many ways is XML cool? Let me count the ways

  </text>

Data Marshalling

  "This is a test." 1.2 7.3 -1.5 1 flattening of structured data items 110011 ... 10000100 ... marshalling 1. flattening of structured data items 2. converting data to external (network) representation host A "Thi i t t " unmarshalling 1. convert data to internal representation 2. rebuild data structures. "This is a test."

  1.2 7.3 -1.5 External to internal representation and vice versa is not required - if the two sides are of the same host type; - if the two sides negotiates at connection. host B

Text-based protocols

  z Data marshalling is at its simplest when the data

exchanged is a stream of characters, or text.

z z

  Exchanging data in text has the additional advantage Exchanging data in text has the additional advantage that the data can be easily parsed in a program and displayed for human perusal. Hence it is a popular practice for protocols to exchange requests and practice for protocols to exchange requests and responses in the form of character-strings. Such protocols are said to be text-based . z

  Many popular network protocols, including FTP (File M l t k t l i l di FTP (Fil Transfer Protocol), HTTP, and SMTP (Simple Mail Transfer Protocol), are text-based.

Event diagram for a protocol session Process 1

  Process 2 request 1 time request 1 response 1 interprocess communication request 2 execution flow process blocked

  E di f l Event diagram for a protocol response2

Event Diagram for a HTTP session

  web server web browser request - an optional header - <command> <document adddress> <HTTP version> request is a message in 3 parts: t i i 3 t

  • optional data for CGI data using post method response - a status line of the format <protocol><status code><description> response is a message consisting of 3 parts: - header information which may span several lines; header information, which may span several lines; - the document itself.

Sequence Diagram Process A Process B

  request 1 response 1 response 1 interprocess communication request 2 response 2

  sequence diagram for a HTTP session Process A Process B request 1 response 1 response 1 interprocess communication request 2 response 2

Protocol

  z

  In a distributed application, two processes perform interprocess communication in a mutually agreed upon protocol.

  z

  The specification of a protocol should include (i) the sequence of data exchange, which can be h f d h hi h b described using a time event diagram.

  (ii) the specification of the format of the data (ii) th ifi ti f th f t f th d t exchanged at each step.

HTTP: A sample protocol

  z

  The Hypertext Transfer Protocol is a protocol for a process (the browser) to obtain a document from a web server process.

  z

  It is a request/response protocol: a browser sends a request to a web server process, which replies with b hi h li i h a response.

The Basic HTTP protocol

  web server web browser request - an optional header - <command> <document adddress> <HTTP version> request is a message in 3 parts: request is a message in 3 parts:

  • optional data for CGI data using post method response - a status line of the format <protocol><status code><description> response is a message consisting of 3 parts: - header information, which may span several lines; , y p ; We will explore HTTP in details later this quarter. - the document itself.

  A sample HTTP session Script started on Tue Oct 10 21:49:28 2000 S i t t t d T O t 10 21 49 28 2000 Escape character is '^]'. Connected to tiedye2-srv.csc.calpoly.edu. Trying 129.65.241.20... 9:49pm telnet www.csc.calpoly.edu 80 Date: Wed, 11 Oct 2000 04:51:18 GMT HTTP response header HTTP/1.1 200 OK HTTP response status line GET / mliu/ HTTP/1.0 GET /~mliu/ HTTP/1 0 HTTP Request HTTP Request Last Modified: Tue, 10 Oct 2000 16:51:54 GMT Last-Modified: Tue, 10 Oct 2000 16:51:54 GMT Server: Apache/1.3.9 (Unix) ApacheJServ/1.0 Accept-Ranges: bytes ETag: "1dd1e-e27-39e3492a" Content-Type: text/html Connection: close Content-Length: 3623 </TITLE> <TITLE> Mei-Ling L. Liu's Home Page <HEAD> <HTML> document content <BODY bgcolor=#ffffff> </HEAD> /HEAD

IPC paradigms and implementations Paradigms of IPC of different levels of abstraction have evolved, with corresponding implementations

  level of abstraction remote procedure/method

  IPC paradigms Example IPC Implementations Unix socket API, Winsock , Remote Procedure Call (RPC), Java RMI data transmission socket API socket API serial/parallel communication

Summary

  Interprocess communications (IPC) is the backbone of distributed computing. In this chapter we have looked at the principles of IPC, including the followings: at the principles of IPC, including the followings: What is interprocess communication? Unicast?

  • Multicast? What is an IPC application programming interface What is an IPC application programming interface
  • (API) and what primitive operations does such an interface provide? Event synchronization: How do processes engaged
  • in IPC synchronize or coordinate the and

  send operations? What role do blocking receive operations play in this regard?

Summary - 2

  Data representation or encoding schemes: Why is

  • data marshalling necessary? What are the two components involved in data marshalling? What are the different levels of abstraction in data encoding? What is meant by object serialization? encoding? What is meant b object seriali ation? What is the difference between connection-
  • oriented and connectionless interprocess oriented and connectionless interprocess communications? Compare and contrast the two.

Summary - 3

  What is an event diagram? How can it be used to

  • describe the sequence of events and their synchronization in a protocol such as the HTTP? What is a sequence diagram? How can it be used
  • to describe the sequence of events in a protocol such d ib h f i l h as the HTTP? Wh t What are the different levels of abstraction in IPC th diff t l l f b t ti i IPC
  • paradigms?