2' InterProcess Communication

1
2. Inter-Process Communication

• Processes and threads
• Clients and servers in DS
• Message-oriented communication
• Remote procedure call (RPC)
• Remote method invocation (RMI)

2
Learning Objectives

• To understand the properties of processes and
  threads, and why threads are particular suitable
  to be used in DSs.
• To gain a good understanding of the features of
  client processes and server processes, and
  examine the major design issues in building
  servers in DS.
• To study general characteristics of inter-process
  communication using high-level middleware
  services based on message-oriented communication
  (in contrast to stream-oriented communication).
• To examine the major services based on
  message-oriented, including message queuing
  services, remote procedure call (PRC), remote
  method invocation (RMI), etc.

3
Processes

• A process is often defined as a program in
  execution. Processes play a fundamental role in
  DSs as they form a basis for communication
  between different machines.
• Because multiple processes may be concurrently
  sharing the same CPU and other resources, the
  operating system (OS), combined with hardware
  support, should ensure the independence and
  correctness of the processes.
• Managing processes incurs a relatively high
  overhead
• process creation a complete independent
  address space needs to allocated, etc.
• switching CPU between two processes
  swapping CPU context, modifying registers of
  memory management unit, etc.

4
Threads

• Similar to process, a thread can be seen as the
  execution of (part) program on a processor.
• A thread system generally maintains only the
  minimum information to allow a CPU to be shared
  by several threads. A thread context often only
  contains the CPU context and other thread
  management information.
• A thread may be blocked, while the other threads
  in the same process are still running, which
  allows blocking system call without blocking the
  entire process which the thread is in. It can
  lead to considerable performance gain.
• Multiple threads may share the same address
  space. Protecting data against inappropriate
  access by threads within a process is left to
  application developers.
• Multithreading is particular suitable to be used
  in DS.

5
Example Multithreaded Servers

• A multithreaded server organized in a
  dispatcher/worker model.

6
Clients

• The main task of most clients is to interact with
  a user and a remote server. A client should
  support the interface to the users, such as
  graphical user interface like X-window.
• The clients should also provide interface
  supporting compound document, which can be
  defined as a collection of documents of
  different kinds (text, images etc), seamlessly
  integrated at the user-interface level.
• Client software may comprise more than just user
  interface. In many cases, parts of the processing
  and data level in client-server application are
  executed on the client.
• Client software may also contains components for
  achieving distribution transparency by hiding
  details concerning the communication with
  servers, the server locations and they are
  replicated or not, etc. It also partly
  responsible for hiding failures and recover from
  failures.

7
Servers General design issues

• A server is a process implementing a specified
  service on behalf of a collection of clients it
  waits for an incoming request from a client,
  processes the request, then waits for the next
  request. There are several design issues.
• How to organize servers
• Interactive server itself handles the
  request, including response if necessary.
• Concurrent server it passes the request to a
  separate thread or another process, then it
  immediately waits for the next one.

8
Servers General design issues

• How clients contact a server
• Each server listens to a specific port
  (endpoint). Clients send requests to a port at
  the machine the server is running, i.e., (IP
  address, port). The IP address of the machine the
  server is running can be obtained by name service
  in Internet.
• The ports can be pre-assigned for some
  well-known services, such as HTTP server for WWW
  has TCP port 80.
• For services (servers) without
  per-assigned ports, the ports can be assigned
  dynamically by the local OS. Clients first have
  to look up the port by contacting a process
  (e.g., daemon) that keeps track of the port of
  each service, through some well-known port (see
  Figure (a) in next slide).

9
Servers General Design Issues
3.7

• Client-to-server binding using a daemon as in DCE
• Client-to-server binding using a superserver as
  in UNIX

10
Servers General design issues

• Instead of keeping track of so many server
  processes, it is often more efficient to have a
  single superserver listening to each port with
  specific service. It forks a process (thread) to
  take care of the incoming request (see Figure (b)
  in previous slide).
• How a server can be interrupted One way is for a
  user to exit the client application then restart
  it immediately or (better method) to develop
  client/server so that a higher priority
  out-of-band data can be sent to interrupt the
  server.
• Whether a server is stateless or not A stateless
  server does not keep information on the state of
  its client, and can change its own state without
  informing any client while a stateful server
  maintains information on its clients. A choice
  should be made but should not affect the service
  provided by the server.

11
Inter-Process Communication

• Inter-process communication (IPC) is at the heart
  of all DSs. Communication in DSs is always based
  on low-level message passing as offered by the
  underlying network.
• An important issue in middleware is to offer a
  higher level of abstraction to easier and better
  express communication between processes than the
  interface for low-level one.
• Middleware is an application logically living in
  the application layer, but it may have its own
  layers, independent of other, more specific
  applications (see next slide).
• Many high-level middleware services are based on
  message-oriented communication, these services
  include remote procedure call (PRC), remote
  method invocation (RMI), message queuing services
  etc.

12
Middleware Protocols
2-5

• An adapted reference model for networked
  communication.

13
Message-Oriented Communication

• Message-oriented communication concentrates on
  exchange more-or-less independent and complete
  units of information, such as request or reply
  messages etc.
• The other form is stream-oriented communication,
  in which timing plays a crucial role. The two
  successive messages may have a temporal
  relationship such as those in video and audio
  streams in multimedia applications.
• Communication system The hosts for application
  execution are connected to communication server
  (CS) for passing messages between two hosts.
  There are some buffers placed in hosts and CSs
  (see the figure in next slide).
• Some basic communication operations send (in
  sender) and receive (in receiver).

14
Persistence and Synchronicity in Communication
2-20

• General organization of a communication system in
  which hosts are connected through a network

15
Message-Oriented Communication

• Transient communication A message is stored by
  communication system only as long as the sending
  and receiving application are executing.
• Persistent communication A message that has been
  submitted for transmission is stored by the
  communication system as long as it takes to
  deliver it to the receiver.
• Asynchronous communication A sender continues
  immediately after it has submitted its message
  for transmission (after executing operation
  send).
• Synchronous communication The sender is blocked
  until its message is stored in a local buffer at
  receiving host, or to the receiver. The strongest
  form is it is blocked until the receiver has
  processed the message (e.g., in request-reply
  protocol).

16
Message-Oriented Transient Communication

• Many DSs and applications are built directly on
  top of the simple message-oriented model (as part
  of middleware solution) offered by the transport
  layer.
• Standard interfaces to the transport layer allows
  users to make use of its entire suit of messaging
  protocols through a simple set of primitives, and
  port an application to different machines.
• Socket interface introduced in Berkeley UNIX is a
  transport level abstraction for inter-process
  communication (IPC).
• A socket is a communication endpoint which an
  application can send message to or receive from.

17
Sockets Communication endpoint
18
Socket

• A socket is usually associated with an Internet
  address and port number, as well as a particular
  protocol (UDP or TCP).
• In using socket, applications generally execute
  socket primitives for IPC. Both TCP and UDP can
  use socket to provide an end-point for
  communication between processes.
• For example, the two frequently-used
  primitives in UNIX
• send and receive primitives in
  connectionless UDP
• sendto and recvfrom
• send and receive primitives in
  connection-oriented TCP
• send and receive

19
Sockets

• Socket primitives for TCP/IP.

20
Sockets used for UDP
21
Sockets used for TCP
Requesting a connection
Listening and accepting a connection
s socket(AF_INET, SOCK_STREAM,0)
s socket(AF_INET, SOCK_STREAM,0)
bind(s, ServerAddress)
listen(s,5)
connect(s, ServerAddress)
sNew accept(s, ClientAddress)
write(s, "message", length)
n read(sNew, buffer, amount)
ServerAddress and ClientAddress are socket
addresses
22
Sockets

• Connection-oriented communication pattern (TCP)
  using sockets.

23
Message-Oriented Persistent Communication

• Message queuing systems (or message-oriented
  middleware - MOM) are an important class of
  message-oriented middleware services for
  supporting asynchronous persistent communication
  (e.g., for email service).
• The essence of these systems is to offer
  intermediate-term storage capacity for message,
  without requiring either the sender or receiver
  to be active during message passing.
• In principle, each application has its own
  private queue to which other applications can
  send messages. The applications communicate by
  inserting messages in specified queues. No
  guarantees are given about when the messages will
  be arriving at receiver and when they will be
  read.

24
Message-Queuing System
2-29

• The general organization of a message-queuing
  system with routers.

25
Remote Procedure Call (RPC)

• RPC is generally implemented over a request-reply
  protocol using transient (often synchronous)
  communication.
• A server process defines in its service interface
  the procedures available for calling remotely.
• How to operate RPC?
• When a process on machine A calls a procedure on
  machine B, calling process on A is suspended, and
  the execution of the called procedure takes place
  on B.
• Information can be transported from the caller to
  the callee in the parameters and can come back
  from callee in the procedure result.
• No message passing or I/O at all is visible to
  the programmer.

26
Remote Procedure Call (RPC)

• The RPC model

27
RPC Characteristics

• Called procedure is in another process which may
  reside in another machine.
• The processes do not share address space.
• Passing of parameters by reference and passing
  pointer values are not allowed.
• Parameters are passed by values.
• Called remote procedure executes within the
  environment of the server process.
• The called procedure does not have access to the
  calling procedure's (clients) environment.

28
RPC Features

• Simple call syntax
• Familiar semantics
• Well defined interface
• Ease of use
• Efficient
• Being able to communicate between processes on
  the same machine or different machines

29
RPC Limitations

• Parameters passed by values only and pointer
  values are not allowed.
• Speed remote procedure calling (and return) time
  (i.e., overheads) can be significantly (1 - 3
  orders of magnitude) slower than that for local
  procedure.
• This may affect real-time design and the
  programmer should be aware of its impact.
• Failure issues RPC is more vulnerable to failure
  (why?).
• The programmers should be aware of the call
  semantics, i.e., programs that make use of RPC
  must have the capability of handling errors that
  cannot occur in local procedure calls.

30
RPC Mechanism
31
RPC Mechanism

• Marshalling (at sender) the process of taking a
  collection of data items and assembling them into
  a form suitable for transmission in a message
• Unmarshalling (at receiver) the process of
  disassembling them on arrival to produce an
  equivalent collection of data items at the
  destination.
• How does the client transfer its call request
  (the procedure name) and the arguments to the
  server via network?
• Marshalling and communication with server
• For each RPC, a (client) stub procedure is
  generated and attached to the (client) program.

32
RPC Mechanism

• Replace the remote procedure call to a (local)
  call to the stub procedure.
• The (codes in the) stub procedure marshals (the
  input) arguments and places them into a message
  together with the procedure identifier (of the
  remote procedure).
• Use IPC primitive to send the (call request)
  message to the server and wait the reply (call
  return) message.

33
RPC Mechanism

• How does the server react the request of the
  client? From which port? How to select the
  procedure? How to interpret the arguments?
• Despatching, unmarshalling, communication with
  client
• A despatcher is provided. It receives the call
  request message from the client and uses the
  procedure identifier in the message to select one
  of the server stub procedures and passes on the
  arguments.

34
RPC Mechanism

• For each procedure at the server which is
  declared (at the sever interface) as callable
  remotely, a (server) stub procedure is generated.
• The task of a server stub procedure is to
  unmarshal the arguments, call the corresponding
  (local) service procedure.
• How does the server transmit the reply back?
• On return, the stub marshals the output
  arguments into a reply (call return) message and
  sends it back to the client.

35
RPC Mechanism

• How does the client receive the reply?
• The stub procedure of the client unmarshals the
  result arguments and returns (local call return).
  Note that the original remote procedure call was
  transformed into a (local) call to the stub
  procedure.

36
RPC Design Issues

• Exception handling
• Necessary because of possibility of network and
  nodes failures
• RPC uses return value to indicate errors
• Transparency
• Syntactic ? achievable, exactly the same syntax
  as a local procedure call
• Semantic ? impossible because of RPC limitation
  failure (similar but not exactly the same)

37
RPC Design Issues

• Delivery guarantees
• Retry request message whether to retransmit the
  request message until either a reply or the
  server is assumed to be failed
• Duplicate filtering when retransmission are
  used, whether to filter out duplicates at the
  server
• Retransmission of replies whether to keep a
  history of reply messages to enable lost replies
  to be retransmitted without re-executing the
  server operations.

38
PRC Design Issues (Call Semantics)

• Maybe call semantics
• After an RPC time-out (or a client crashed and
  restarted), the client is not sure if the remote
  procedure may or may not have been called.
• This is the case when no fault tolerance is built
  into RPC mechanism.
• Clearly, maybe semantics is not desirable.

39
PRC Design Issues (Call Semantics)

• At-least-once call semantics
• With this call semantics, the client can assume
  that the remote procedure is executed at least
  once (on return from the remote procedure).
• Can be implemented by retransmission of the
  (call) request message on time-out.
• Acceptable only if the servers operations are
  idempotent.
• An idempotent operation f is an operation that
  can be performed repeatedly with the same effect
  as if it had been performed exactly once, that is
  f(x) f(f(x)).

40
PRC Design Issues (Call Semantics)

• At-most-once call semantics
• When an RPC returns, it can be assumed that the
  remote procedure has been called exactly once or
  not at all.
• Implemented by the server's filtering of
  duplicate requests (which are caused by
  retransmissions due to IPC failure, slow or
  crashed server) and caching of replies (in reply
  history).

41
PRC Design Issues (Call Semantics)

• This ensures the remote procedure is called
  exactly once if the server does not crash during
  execution of the remote procedure.
• When the server crashes during the remote
  procedure 's execution, the partial execution may
  lead to erroneous results.
• In this case, we want the effect that the remote
  procedure has not been executed at all.

42
Summary I

• Threads in DSs are particular useful to continue
  using CPU when a blocking I/O operation is
  performed. Using threads, it becomes possible to
  build highly efficient servers running multiples
  threads in parallel.
• Client-server model is the most useful model in
  DS. Client processes generally implement user
  interfaces. Client software is further aimed at
  achieving distribution transparency.
• Servers are often more complicated than clients.
  There are some design issues including either
  implementing interactive or concurrent services,
  how to contact a server, being stateless server
  or not, and how to handle interrupt in servers.

43
Summary II

• In traditional network applications,
  communication is often based on low-level
  message-passing primitives (e.g., send and
  receive) offered by transport layer. The
  middleware in DS tries to offer a higher level of
  abstraction, such as RPC/RMI, for better
  expression of communication between processes.
• In message-oriented models, the persistent
  communication is that a message, during
  transmission, is stored by the communication
  system as long as it takes to deliver it. Neither
  the sender nor the receiver needs to be up and
  running during message transmission.
• For transient communication in message-oriented
  model, no storage facilities are offered, so that
  receiver must be prepared to accept message when
  it is sent.

44
Summary III

• Communication can also be synchronous or
  asynchronous in terms of blocking sender (synch.)
  or not (asynch.).
• Message-oriented middleware models generally
  offer persistent asynchronous communications, and
  are used where RPC/RMI is not appropriate.
• RPC is one of the most widely used (higher level)
  abstraction, in which it is allowed for a process
  to call procedure in other process, even on
  different machines. In RPC, a service is
  implemented by means of procedure whose body is
  executed at a server.
• RPC aims at achieving access transparency, but
  offers relatively poor support for passing
  reference. It is based on transient (usually
  synchronous) communication.