95702-Interprocess Communications

作者 QIFAN 日期 2016-10-31
95702-Interprocess Communications

Distributed Systems for Information Systems Management(95702), Fall16, Carnegie Mellon University
👉👉👉 笔记大纲


  • Middleware: sits between the operating system and applications on different servers and simplifies the development of applications that leverage services from other applications. This allows programmers to create business applications without having to custom craft integrations for each new application.
  • External Data Representing: an agreed standard for the representaton of data structures and primitive values.
  • Marshalling: the process of taking a collection of data items and assembling them into a form suitable for transmission in a message.
  • Unmarshalling: the preocess of disassembling them on arrival into an equivaleng representation at the destination.
  • Big endian: store the most significant byte in the smallest address
  • Little endian: store the least significant byte in the smallest address
  • IDL: interface description language or interface definition language (IDL), is a specification language used to describe a software component’s application programming interface (API). IDLs describe an interface in a language-independent way, enabling communication between software components that do not share one language.

Inteperability Problems

Passing values over a network maybe problematic:

  1. If two sides are same, ok
  2. If two sides have different ways of representing data, they may differ in:
    • big indian or little indian, byte ordering
    • floating pointing representation
    • character encodings(ASCII, UTF-8, Unicode, EBCDIC)


1. Passing values

Marshlling and Unmarshalling

Marshalling and unmarshalling(find definitions in #Terminologies) are usually carried out by the middleware layer.

Store Values into Memory

There are two ways of storing values into memory: Big Endian and Little Endian(find definitions in #Terminologies). The ways are in reverse order. It is important for receiver to know which way is using.

Three Approches to External Data Representation

CORBA’s CDR (Common Data Representation)

    • Common Object Request Broker Architecture, is an architecture and specification for creating, distributing, and managing distributed program objects in a network.
    • Formed by Object Management Group (OMG)
    • It allows programs at different locations and developed by different vendors to communicate in a network through an “interface broker.”
    • central idea is to pass around objects by value and references to objects.
  • Why CORBA’s CDR?
    Because binary data may be used by different programming languages.
  • How’s CDR?
    • both sides have the IDL(find definitions in #Terminologies) beforehand
    • can be used by a variaty of programming languages
    • data is represented in binary form
    • byte ordering from sender is specified in each message
    • may be used for arguments or return values in RMI
  • Example
    struct with value: {“Smith”, “London”, 1934}
index in sequence of bytes content notes
0–3 5 length of string
4–7 “Smit”
8–11 “h/s/s/s/s” “h” + 4 spaces
12–15 6 length of string
16–19 “Lond”
20-23 “on/s/s” “on” + 2 spaces
24–27 1934 unsigned long

Java Serialization

  • The activity of falttening an object or even a connected set of objects
  • store an obejct to disk
  • transmit an object as an argument or return value in Java RMI
  • holds not only class infomation but also instance data
  • can be loaded at runtime
  • may not know the type of object before hand

Web Service use of XML or JSON

readable? yes yes
character encoding varies, need an agreement UTF-8
binary message representations any any
content constrain message may constrained by grammar message may constrained by grammar
interoperable? yes, support marshalling and unmarshalling yes, support marshalling and unmarshalling
speed verbose and slow
domains standards and tools still under development RESTful applications

2. Address Remote Object

In systems like Java RMI or CORBA, we need a way to pass pointer to remote objects
reminds me of URL.

Representation of Remote Object Reference

32 bits 32 bits 32 bits 32 bits
internet address port number time object number interface of remote object

3. Communication

UDP Based Request Reply Protocol

❗️Client side:

  • execution

    b = doOperation(r,2,b)
  • API

    * sends a request message to the remote object and returns the reply.
    * The arguments specify the remote object, the method to be invoked and the
    * arguments of that method.
    public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)

❗️Server side:

  • execution

  • API

    * acquires a client request via the server port.
    public byte[] getRequest ();
    * sends the reply message reply to the client at its Internet address and port.
    public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);

Request Reply Message Structure

Failure Model of UDP Request Reply Protocol

Problem 1

UDP stype doOperation may timeout while waiting


  • return to caller passing an error message
  • but perhaps the request was received and the response was lost, so, we might write the client to try and try until convinced that the receiver is down

Problem 2

Duplicate messages


  • re-computes the reply (in the case of idempotent operations)
  • or returns a duplicate reply from its history of previous

RPC Exchange Protocols

Name Client Msg sent by Server Msg sent by Client
R Request
RR Request Reply
RRA Request Reply Acknowledge reply

R = no response is needed and the client requires no confirmation
RR = a server’s reply message is regarded as an acknowledgement
RRA = Server may discard entries from its history