Chapter 4 Interprocess Communication

1
Chapter 4Interprocess Communication

• Choe, Hyun Jong
• Dept. of Computer Education
• Korea National Univ. Of Education

2
Chapter Overview

• Why IPC?
• Design Considerations
• Client-Server Communication
• Group Communication
• Case Study IPC in UNIX

3
Interaction model in D.S.

• A principal goal of D.S.
• A single system image
• -gt resource sharing
• ( by concurrency cooperation)
• Common form of interaction
• Client-server interaction model
• Interprocess communication(IPC)

4
Principal Functions

• To allow communication between components(process)
  
• To shield one process from failure of another
• To provide modularity by a well defined interface
  mechanism
• To hides distinction between local and remote
  communications

5
Abstraction of communication subsystem

• To regard a network as another I/O device
• Primitive roles write(send) and read(receive)
• Request and reply
• Abstraction of message passing required to
  execute a procedure at a server
• Remote procedure call(RPC)
• To Hide the separation between a client and a
  server
• To make invocation of a remote procedure at a
  server same as that of a local procedure

6
Design considerations in IPC

• Data representation
• Marshalling
• Calling semantics
• Addressing
• Reliable delivery
• Versatility

7
Data representation (1)

• Data representation problem
• Different type representation in different
  computers(platforms)
• Character coding ASCII, Unicode
• How to solve this problem?
• To use agreed external data representation two
  conversions necessary
• To use senders or receivers format and convert
  at the other end

8
Data representation (2)

• External data representation
• An agreed standard for the representation for
  data structures and primitive values
• SUN Microsystems XDR
• CORBAs CDR
• JAVAs object serialization

9
Marshalling (1)

• Marshal tr. To arrange or place (troops, for
  example) in line for a parade To arrange, place,
  or set in methodical order To enlist and
  organize trying to marshal public support.
• Marshalling
• Linearization of an operation invocation
• Convert the type of data into a common type
• Pack linearized data into a message

10
Marshalling (2)

• Unmarshalling
• Reverse operation of marshalling at the receiving
  peer
• Object serialization
• Activity of flattening an object into a serial
  form for storing on disk or transmitting in a
  message

11
CORBAs CDR

• Common Object Request Broker Architecture by OMG
• Common Data Representation(CDR)
• To support types in CORBA remote object
  invocations
• 15 primitive types short, long, float, double,
  char, boolean, et al.
• Characters using an agreed character set between
  client and server

12
CORBA CDR Example

• struct Person
• string name
• string place
• long year
• Example
• Smith,
• London,
• 1934

13
CORBA IDL

• CORBA IDL(Interface Definition Language)
• IDL compilers will generate marshalling and
  unmarshalling operations that transforms data
  objects into CDR format
• Sender and recipient have common knowledge of the
  order and types of the data items in a message

14
Calling semantics (1)

• Remote operation invocation may need a different
  behavior than local one
• Sender may not need a result either at all or
  immediately
• Sender may want to do other operations in
  parallel
• Semantics
• Synchronous
• Delayed synchronous
• asynchronous

15
Calling semantics (2)

• RPC exchange protocols
• R/RA/RRA

16
Addressing

• Identification of communication peers
• Location-independent identifiers
• Functional addressing port
• Globally unique identifier IP,
• Remote Object References

17
Remote Object References

• Needed when a client invokes an object that is
  located on a remote server
• Reference needed that is unique over space and
  time
• A general format proposal

18
Reliable Delivery (1)

• End-to-end argumentSaltzer et al.
• Error recovery in lower levels of protocols is
  only useful for purpose of increasing efficiency
• Possible causes for retransmission
• Server crashes
• Request gets lost
• IPC should provide some level of failure
  transparent but also failure visibility

19
Reliable Delivery (2)

• Retransmission mechanism
• Reply can be considered an acknowledgement
• Selective retransmission sequence number
• Explicit acknowledgement
• Retransmission timer

20
Versatility

• Types of IPC
• Remote operation
• Bulk data transfer
• Group communication
• Continuous media transfer
• QoS
• Real-time retry is better than retransmission
• Stream-oriented steady and low delay but packet
  lost is ok.

21
Client-server communication

• Often built over UDP datagrams
• Client-server protocol consists of request /
  response pairs, hence no acknowledgements at
  transport layer are necessary

22
Request-reply message

• Request-reply message structure

• Operation of the request-reply at page 146
• HTTP request message at page 152
• HTTP rely message at page 153

23
Group communication

• Purposes of multicast messages
• Fault tolerance based on replicated services
  client requests are multicast to all, each of
  which performs an operation
• Locating objects in distributed services
• Better performance through replicated data each
  time the data changed, the new values is
  multicast
• Propagation of event notification news system
• IP multicast An implementation of group
  communication

24
Reliability and Ordering of multicast

• Reliable multicast
• Some applications requires a multicast protocol
  that is more reliable than IP multicast atomic
  multicast(all or nothing)
• Ordering of multicast
• Concurrent execution of update requests at
  replicas may result in inconsistency among
  replicated data serial equivalence of update
  requests is required
• Expense of ordering should also be considered

25
Multicast peer joins a group

• Page at 156

26
Case study-IPC in UNIX (1)

• Socket used for datagrams

27
Case study-IPC in UNIX (2)

• Socket used for streams