Process and InterProcess Communication - PowerPoint PPT Presentation


PPT – Process and InterProcess Communication PowerPoint presentation | free to view - id: 9d5f9-Zjc2M


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Process and InterProcess Communication


Multiple threads may share the same address space. ... Using threads, it becomes possible to build highly efficient servers running ... – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 44
Provided by: CIT788


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Process and InterProcess Communication

Process and Inter-Process Communication
  • Processes and Threads
  • Server Process Design Issues
  • Middleware Protocols
  • Message-Oriented Communication
  • Sockets
  • Message-Oriented Persistent Communication
  • RPC

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

  • 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
  • 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.

  • 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

Example Multithreaded Servers
Fr. Tanenbaum
  • A multithreaded server organized in a
    dispatcher/worker model.

  • 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, part 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

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

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

Servers General Design Issues
Fr. Tanenbaum
  • Client-to-server binding using a daemon as in DCE
  • Client-to-server binding using a superserver as
    in UNIX

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

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

Middleware Protocols
Fr. Tanenbaum
  • An adapted reference model for networked

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)

Persistence and Synchronicity in Communication
Fr. Tanenbaum
  • General organization of a communication system in
    which hosts are connected through a network

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

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
  • 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

Sockets Communication Endpoint
Fr. Dollimore
  • 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
  • send and receive

  • Socket primitives for TCP/IP

Sockets used for UDP
Fr. Dollimore
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)
connect(s, ServerAddress)
sNew accept(s, ClientAddress)
write(s, "message", length)
n read(sNew, buffer, amount)
ServerAddress and ClientAddress are socket
Fr. Dollimore
Fr. Tanenbaum
  • Connection-oriented communication pattern (TCP)
    using sockets

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

Message-Queuing System
Fr. Tanenbaum
  • The general organization of a message-queuing
    system with routers.

Remote Procedure Call (RPC)
  • RPC is generally implemented over a request-reply
    protocol using transient (often synchronous)
  • 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

Remote Procedure Call (RPC)
  • The RPC model

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

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

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
  • This may affect real-time design and the
    programmer should be aware of its impact
  • Failure issues RPC is more vulnerable to failure
  • 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

RPC Mechanism
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
  • How does the client transfer its call request
    (the procedure name) and the arguments to the
    server via network?

RPC Mechanism
  • Marshalling and communication with server
  • For each RPC, a (client) stub procedure is
    generated and attached to the (client) program
  • 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

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
  • 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
  • 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

RPC Mechanism
  • 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
  • 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

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)

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
  • Retransmission of replies whether to keep a
    history of reply messages to enable lost replies
    to be retransmitted without re-executing the
    server operations

RPC 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

RPC 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
  • 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))

RPC 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
  • 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

  • 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

  • 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

  • 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

  • Dollimore chapters 4 and 6.4, 6.5
  • Tanenbaum chapters 2.2, 2.4, 2.5 and 3.1 3.3