CTIS 490 DISTRIBUTED SYSTEMS

1
CTIS 490DISTRIBUTED SYSTEMS

• WEEK 4
• DISTRIBUTED SYSTEMS
• COMMUNICATION

2
INTRODUCTION

• Inter-process communication is at the heart of
  all distributed systems, i.e. the ways that
  processes on different machines exchange
  information.
• Communication mechanisms for distributed systems
  are harder than mechanisms available for
  non-distributed systems, such as shared memory.
• The rules that communicating processes must obey
  are known as protocols, and these protocols are
  structured in the form of layers.
• There are three widely used distributed
  communication models
• Remote Procedure Call (RPC)
• Message-Oriented Middleware (MOM)
• Data streaming

3
FUNDAMENTALS

• When process A wants to communicate with process
  B, it first builds a message, and then executes a
  system call that causes the operating system to
  send the message over the network to process B.
• Sound simple?
• How many volts should be used to signal a 0-bit?
• How many volts should be used to signal a 1-bit?
• How does the receiver know which is the last bit
  of the message?
• How can it detect if a message has been damaged
  or lost?
• How long are numbers and strings, and how are
  they represented?

4
FUNDAMENTALS

• The ISO OSI model identifies the various levels
  involved,
• gives them standard names, and points out which
  level
• should do which job.

5
LAYERED PROTOCOLS

• The OSI model is designed to allow open systems
  to communicate (an open systems is one that is
  prepared to communicate with any other open
  system by using standard rules that govern the
  format, contents, and meaning of the messages
  sent and received).
• These rules are formalized in what are called
  protocols.
• There are two types of protocols
• Connection oriented protocols before exchanging
  data, the sender and receiver first establish a
  connection. When they are done, they must release
  the connection. The telephone is a connection
  oriented communication system.

6
LAYERED PROTOCOLS

• Connectionless protocols no setup in advance is
  needed. The sender just transmits the first
  message when it is ready. Dropping a letter in a
  mailbox is an example.
• In the OSI layer, communication is divided to
  seven layers. Each layer provides an interface to
  the one above it.
• For example, when process A on machine 1 wants to
  communicate with process B on machine 2, it
  builds a message and passes the message to the
  application layer.
• The application layer software then adds a header
  to the front of the message and passes the
  resulting message to the presentation layer.
• The physical layer actually transmits the message.

7
LAYERED PROTOCOLS

• When the message arrives at the machine 2, it is
  passed
• upward, with each layer stripping off and
  examining its
• own header.

8
LOWER-LEVEL PROTOCOLS

• The three lowest layers of the OSI protocol suite
  implement the basic functions of the computer
  network
• Physical layer concerned with transmitting 0s
  and 1s, how many volts to use, how many bits per
  second, etc.
• Data link layer puts a special bit pattern as
  well as computing a checksum by adding up all the
  bytes. If receiving data link layer calculates
  the same result, the package is considered valid.
• Network layer chooses the best path, called
  routing, from source to destination. Most widely
  used protocol is the Internet Protocol (IP).

9
HIGHER-LEVEL PROTOCOLS

• Transport layer assigns a sequence number to
  packets and breaks them into small pieces for
  transmission. The most widely used protocol is
  the Transmission Control Protocol (TCP). There is
  also connectionless protocol called Universal
  Datagram Protocol (UDP).
• Above the transport layer, OSI distinguished
  three additional layers. In practice, only the
  application layer is used.
• Session layer keeps track of which party is
  currently communicating.
• Presentation layer concerns with converting
  bits to data structures, compression, encryption,
  etc.

10
MIDDLEWARE PROTOCOLS

• Middleware is an application that logically lives
  in the application layer.
• There are numerous protocols to support a variety
  of middleware services.
• For example, distributed commit protocols
  establish that in a group of processes either all
  processes carry out a particular operation, or
  that the operation is not carried out at all.
• For example, distributed locking protocols by
  which a resource can be protected against
  simultaneous access by a collection of processes
  are part of middleware services.
• In general, middleware protocols support
  high-level communication services.

11
MIDDLEWARE PROTOCOLS

• An adapted reference model for networked
  communication.

12
TYPES OF COMMUNICATION

• Persistent communication a message that has
  been submitted for transmission is stored by the
  communication middleware as long as it takes to
  deliver it to the receiver.
• The core of an electronic mail system can be seen
  as a middleware communication service in which
  communication is persistent.
• Transient communication a message is stored by
  the communication system only as long as the
  sending and receiving applications are executing.
• Typically, all transport level communication
  services offer only transient communication. The
  communication system consists of
  store-and-forward routers. If a router cannot
  deliver a message to the next one or the
  destination host, it will simply drop the message.

13
TYPES OF COMMUNICATION

• Asynchronous communication sender continues
  immediately after it has submitted its message
  for transmission.
• The message is temporarily stored by the
  middleware upon submission.
• Synchronous communication sender is blocked
  until its request is known to be accepted.
• There are essentially three points where
  synchronization can take place
• Sender may be blocked until the middleware
  notifies that it will take over transmission of
  the request.
• Sender may be blocked until its request has been
  delivered to the intended recipient.
• Sender may be blocked until request is fully
  processed and a response is returned.

14
TYPES OF COMMUNICATION

• Viewing middleware as an intermediate distributed
  service in
• application-level communication.

15
TYPES OF COMMUNICATION

• Various combinations of persistence and
  synchronization occur in practice. For example
• Remote procedure calls transient communication
  with synchronization after the request has been
  fully processed.
• Message-queuing systems persistent
  communication with synchronization at request
  submission.
• The types of communication that are discussed so
  far are discrete. Each message forms a complete
  unit of information.
• In contrast, streaming involves sending multiple
  messages where they are related to each other by
  the order they are sent.

16
REMOTE PROCEDURE CALL (RPC)

• Idea is simple, and it is introduced in 1984.
• It allows programs to call procedures located on
  other machines.
• When a process on machine A calls a procedure on
  machine B, the calling process on A is suspended,
  and execution of the called procedure takes place
  on B.
• Information can be transported from the caller to
  the callee in the parameters and come back in the
  procedure result.
• No message passing is visible to the programmer.

17
CONVENTIONAL PROCEDURE CALL

• A call in C count read(fd, buf, nbytes)
• Parameter passing mechanisms(call-by-value,
  call-by-reference)

18
CLIENT AND SERVER STUBS

• The idea behind RPC is to make a remote procedure
  call look as much possible like a local one.
• When read is actually a remote procedure (for
  example, one that will run on the file servers
  machine), a different version of read, called a
  client stub is used.
• Client stub packs parameters into a message and
  requests that message to be sent to the server.
• When the message arrives at the server, the
  servers operating system passes it up to a
  server stub, which is the server-side equivalent
  of a client stub.

19
CLIENT AND SERVER STUBS
20
CLIENT AND SERVER STUBS

• The client procedure calls the client stub in the
  normal way.
• The client stub builds a message and calls the
  local operating system (OS).
• The clients OS sends the message to the remote
  OS.
• The remote OS gives the message to the server
  stub.
• The server stub unpacks the parameters and calls
  the server.
• The server does the work and returns the result
  to the stub.
• The server stub packs it in a message and calls
  its local OS.
• The servers OS sends the message to the clients
  OS.
• The clients OS gives the message to the client
  stub.
• The stub unpacks the result and returns to the
  client.

21
PASSING VALUE PARAMETERS

• Packing parameters into a message is called
  parameter marshaling.
• For example, add(i,j)

22
PASSING VALUE PARAMETERS

• As long as the client and server machines are
  identical, and all the parameters are scalar
  types (integers, booleans, etc.) this model works
  fine.
• However, in a large distributed system, multiple
  machine types are present. Each machine often has
  its own representation for numbers, characters,
  and other data items.
• For example, IBM mainframes use EBCDIC character
  code, whereas IBM personal computers use ASCII.
• For example, Intel Pentium numbers the bytes from
  right to left (little endian), whereas Sun SPARC
  numbers them the other way (big endian).

23
PASSING REFERENCE PARAMETERS

• A pointer is only meaninful only within the
  address space of the process in which it is being
  used.
• In our read example, if the second parameter is
  1000 on the client, we cannot just pass the
  number 1000 to the server and expect it to work.
• As a result, call-by-reference is replaced by
  copy/restore, copying the array into the message
  and sending it over to the server.

24
DISTRIBUTED COMPUTING ENVIRONMENT RPC

• The Distributed Computing Environment (DCE) RPC
  was developed by Open Software Foundation, and it
  has been adopted in Microsofts base system for
  distributed computing, DCOM.
• The DCE RPC system consists of a number of
  components, including languages, libraries, and
  utility programs.
• Interface Definition Language (IDL) is used to
  specify the communication mechanism between the
  client and the server. It permits procedure
  declarations in a form closely resembling
  function prototypes in ANSI C.

25
DISTRIBUTED COMPUTING ENVIRONMENT RPC

• IDL files can also contain type definitions and
  constant declarations needed to correctly marshal
  parameters and unmarshal results.
• A crucial element in every IDL file is a globally
  unique identifier for the specified interface.
• The first step in writing a client-server
  application is calling the uuidegen program,
  asking it to generate a prototype IDL file
  containing an interface identifier guaranteed
  never to be used again in any interface generated
  anywhere by uuidengen.
• Uniqueness is ensured by encoding in it the
  location and time of creation.

26
DISTRIBUTED COMPUTING ENVIRONMENT RPC

• The next step is editing the IDL file, filling in
  the names of the remote procedures and their
  parameters.
• When the IDL file is complete, the IDL compiler
  is called to process it. The output of the IDL
  compiler consists of three files
• A header file (e.g. interface.h - in C)
• The client stub
• The server stub
• The header file should be included in both the
  client and server code.
• The next step is to write the client and server
  code.
• Then the client code and client stub linked
  together. The same thing is done in the server
  side.

27
DISTRIBUTED COMPUTING ENVIRONMENT RPC
28
BINDING A CLIENT TO A SERVER

• To allow a client to call a server, it is
  necessary that the server be registered and
  prepared to accept incoming calls.
• Registration of a server makes it possible for a
  client to locate the server and bind to it.
• Server location is done in two steps
• Locate the servers machine
• Locate the server (i.e. the correct process) on
  that machine
• In DCE, a table of (server, end pointport) pairs
  is maintained by a process called DCE daemon.

29
BINDING A CLIENT TO A SERVER
30
BINDING A CLIENT TO A SERVER

• For example, a client wants to bind to a video
  server that is locally known under the name
  /local/multimedia/video/movies
• It passes this name to the directory server,
  which returns the network address of the machine
  running the server.
• The client then goes to the DCE daemon on that
  machine (which has a well-known end point), and
  asks it to look up the end point of the video
  server in its end point table.
• The RPC can now take place.

31
DISTRIBUTED OBJECTS

• Remote Method Invocation (RMI) RPC Object
  Orientation
• Allows objects living in one process to invoke
  methods of an object living in another process
• Java RMI
• Common Object Request Broker Architecture (CORBA)
• Microsoft Distributed Component Object Model
  (DCOM)
• Simple Object Access Protocol (SOAP)
• We will cover Distributed Objects in detail
  during Week 12.

32
DISTRIBUTED OBJECTS
33
DISTRIBUTED OBJECTS
Server
Client
Request
doOperation
getRequest
message
select object
execute
(wait)
method
Reply
sendReply
message
(continuation)
34
MESSAGE-ORIENTED COMMUNICATION

• It cannot be always assumed that the sending and
  receiving processes are executing at the same
  time when the communication must be exchanged.
• The inherent synchronous nature of RPCs, by which
  a client is blocked until its request has been
  processed, sometimes needs to be replaced by
  another method of communication.
• One alternative is the use message-oriented
  communication.

35
MESSAGE-ORIENTED TRANSIENT COMMUNICATION

• Many distributed systems and applications are
  built directly on top of the simple
  message-oriented model offered by the transport
  layer.
• The interface of the transport layer is
  standardized to allow programmers to make use of
  its entire suite of messaging protocols through a
  set of primitives.
• Berkeley sockets provide this kind of an
  interface.
• A socket is a communication end point to which an
  application can write data that are to be sent
  over the network and from which incoming data can
  be read.

36
MESSAGE-ORIENTED TRANSIENT COMMUNICATION
37
MESSAGE-ORIENTED TRANSIENT COMMUNICATION

• Servers generally execute the first four
  primitives in the
• order given.

38
MESSAGE-ORIENTED TRANSIENT COMMUNICATION
39
MESSAGE-ORIENTED PERSISTENT COMMUNICATION

• Message-Oriented middleware services known as
  message-queuing systems or Message-Oriented
  Middleware (MOM) provide support for persistent
  asynchronous communication.
• Most widely used MOM products are
• IBM WebSphere/MQSeries
• Microsoft - MSMQ
• The essence of these systems is that they offer
  intermediate term storage capacity for messages.
• An important difference with Berkeley sockets is
  that message-queuing systems are targeted to
  support message transfers that are allowed to
  take minutes instead of seconds or milliseconds.

40
MESSAGE-QUEUING MODEL

• In a message-queuing system, applications
  communicate by inserting messages in specific
  queues.
• An application can have its own private queue, or
  it can share it with other applications.
• The system permits communications to be
  loosely-coupled i.e. there is no need for the
  receiver to be executing when a message is being
  sent to its queue.
• Likewise, there is no need for the sender to be
  executing at the moment its message is picked up
  by the receiver.

41
MESSAGE-QUEUING MODEL
42
MESSAGE-QUEUING MODEL

• Messages contain any data.
• Message size may be limited, but the system takes
  care of fragmenting and assembling large messages
  transparently.
• Basic interface to applications is very simple.
• Put, Get, Poll, and Notify (callback function)
  are the basic interfaces to a queue in a
  message-queuing system.

43
GENERAL ARCHITECTURE OF A MESSAGE-QUEUING SYSTEM

• Messages can be put only into queues that are
  local to the sender. Such a queue is called
  source queue.
• Likewise, messages can be read only from local
  queues.
• However, a message put into a queue will contain
  the specifications of a destination queue to
  which it should be transferred.
• It is the responsibility of the message-queuing
  system to provide queues to senders and receivers
  and take care that messages are transferred.
• The system maintains a mapping of queues to
  network locations via a distributed database of
  queue names.

44
GENERAL ARCHITECTURE OF A MESSAGE-QUEUING SYSTEM
45
GENERAL ARCHITECTURE OF A MESSAGE-QUEUING SYSTEM

• Queues are managed by queue managers.
• Normally, a queue manager interacts directly with
  the application.
• However, there are also special queue managers
  that operate as routers, or relays they forward
  incoming messages to other queue managers.
• Relays are very convenient. For example, in many
  message queuing systems, there is no dynamic
  queue-to-location mappings. The topology of the
  queuing network is static. In large scale
  systems, this can be a huge problem.
• By routing mechanism, only the relays need to be
  updated when queues are added or removed while
  queue manager has to know only the nearest router.

46
ORGANIZATION OF A MESSAGE-QUEUING SYSTEM WITH
ROUTERS
47
MESSAGE BROKERS

• An important application area of message-queuing
  systems is integrating existing and new
  applications into a coherent distributed
  information system.
• Integration requires that applications can
  understand the messages.
• The problem is that each time an application is
  added to the distributed system that requires a
  separate message format, other applications have
  to be modified.
• In message-queuing systems, message conversions
  are handled by special nodes known as message
  brokers.
• A message broker acts as an application level
  gateway. Its main purpose is to convert incoming
  messages so that they can be understood by the
  destination application.

48
MESSAGE BROKERS

• For example, a message contains a table from a
  database in which records are separated by a
  special end-of-record.
• If the destination application expects a
  different delimiter, a message broker can convert
  this message.

49
STREAM-ORIENTED COMMUNICATION

• Streaming media is a media that is continously
  recevied by and displayed to the end user while
  it is being delivered by the provider.
• Streaming media is distributed over
  telecommunication networks.
• Multimedia is a media that uses multiple forms of
  information content, like audio and video.
• In general multimedia content is large, so media
  storage and transmission costs are significant.
• Media is generally compressed for both storage
  and streaming.
• Streaming media can be on-demand or live.

50
STREAM-ORIENTED COMMUNICATION

• In recent years, there has been explosive growth
  of new applications on the Internet
• Streaming audio and video
• IP telephony
• Teleconferencing
• Distance learning
• These multimedia networking applications are
  different from download-and-then-play
  applications, and they are called
  continuous-media applications.
• They require services different from those
  traditional ones.
• These applications are similar to traditional
  radio and television (broadcasting), except that
  audio and video contents are transmitted over the
  Internet.

51
STREAM-ORIENTED COMMUNICATION

• One key issue to support networked multimedia
  applications is how to get the high quality for
  the communications latency on the best-effort
  Internet which provides no latency guarantee.
• Best-effort delivery describes a network service
  in which the network does not provide any
  guarantees that data is delivered with certain
  requirements.
• In a best-effort network, all users obtain best
  effort services, for example unspecified bit rate
  depending on the current traffic load.
• Another key issue is how to improve Internet
  architecture to provide support for the services
  required by multimedia applications, for example
  through the next generation networklayer protocol
  IPv6.

52
STREAM-ORIENTED COMMUNICATION

• In RPC and message-oriented communication timing
  does not matter, i.e. even though a system may
  perform too slow or too fast, timing has no
  effect on correctness of the distributed system.
• However, there are forms of communication in
  which timing plays a critical role, for example,
  audio and video streams.
• In continuous media, the sequence relationships
  between different data items are fundamental to
  correctly interpreting what the data actually
  means.
• For example, motion can be represented by a
  series of images in which successive images must
  be displayed at a uniform spacing T in time,
  typically 30-40 msec per image.
• Correct reproduction requires not only showing
  the still images in correct order, but also at a
  constant frequency of 1/T images per second.

53
DATA STREAMS

• To capture the exchange of time-dependent
  information, distributed systems generally
  provide support for data streams.
• A data stream is a sequence of data units. For
  example, playing an audio file requires setting
  up a continuous data stream between the file and
  the audio device.
• To capture timing aspects, a distinction is made
  between three different transmission modes
• Asynchronous transmission mode the data items
  are transmitted one after the other, but there
  are no further timing constraints on when
  transmission of items should take place.
• A file can be transferred as a data stream, it is
  irrelevant when the transfer of each data item
  completes.

54
DATA STREAMS

• Synchronous transmission mode there is a
  maximum end-to-end delay defined for each unit in
  a data stream.
• A sensor may sample temperature at a certain rate
  and pass it through the network. The end-to-end
  propagation time should be lower than the time
  interval taking the samples.
• Isochronous transmission mode it is necessary
  that data units are transferred on time. This
  means that data transfer is subject to maximum
  and minimum end-to-end delay, also referred to as
  bounded (delay) jitter.
• Distributed multimedia systems.

55
DATA STREAMS

• Data streams can be simple or complex
• Simple stream consists of only a single
  sequence of data items.
• Complex stream consists of several related
  simple streams called sub-streams.
• Stereo audio can be transmitted by means of
  complex stream, each used for a single audio
  channel. These sub-streams must be continuously
  synchronized.
• A movie can also be transmitted by means of
  complex stream. For example, stream 1 video,
  stream 2 and 3 audio, stream 4 subtitles for the
  deaf.
• Distribution of data streams involves the
  following technologies and techniques
• Compression
• Quality Of Service (QoS)
• Synchronization

56
DATA STREAMS
57
COMPRESSION

• The Moving Picture Experts Group (MPEG) is a
  working group of ISO charged with the development
  of video and audio encoding standards.
• MPEG has standardized the following compression
  formats
• MPEG-1 Initial video and audio compression
  standard. It includes the popular Layer 3 (MP3)
  audio compression format.
• MPEG-4 Expands MPEG-1 to be used by the
  streaming media.
• MPEG-21 Describes the standard as a multimedia
  framework.
• A multimedia framework is a set of software
  libraries that handles media on a computer and
  through a network. It is used by applications
  such as media players and audio or video editors.
  They are available for different operating
  systems.
• For example, Microsoft has DirectShow, QuickTime,
  and Media Foundation (Vista).

58
QUALITY OF SERVICE

• Quality of Service (QoS) refers to control
  mechanisms that can provide different priority to
  different users or data flows, or guarantee a
  certain level of performance to a data flow in
  accordance with requests from the application
  program.
• QoS guarantees are important if network capacity
  is limited, especially for streaming multimedia
  applications.
• A network protocol that supports QoS may agree on
  a traffic contract with the application software
  and reserve capacity in the network nodes during
  a session establishment phase.
• During the session, it may monitor the achieved
  level of performance, for example the data rate
  and delay, and dynamically control scheduling
  priorities in the network nodes.

59
QUALITY OF SERVICE

• A best-effort network does not support QoS.
• Bit rate
• Dropped packets
• Delay
• Out-of-order delivery
• Given that the underlying system offers only
  best-effort delivery service, a distributed
  system can try to conceal as much as possible the
  lack of QoS.
• Internet provides a means for differentiating
  classes of data by means of differentiated
  services.
• A sending host can mark outgoing packets as
  belonging to one of several classes, including an
  expedited forwarding class that specifies a
  packet should forwarded by the current router
  with absolute priority.
• The assured forwarding class defines a range of
  priorities.

60
QUALITY OF SERVICE

• Besides these network-level solutions, a
  distributed system can provide buffers to reduce
  jitter.
• Assuming that packets are delayed with a certain
  variance, the receiver stores them in a buffer
  for a maximum amount of time.

61
SYNCHRONIZATION

• In multimedia systems, different systems should
  be synchronized, i.e. temporal relationships
  should be maintained between them.
• For example, during a slide presentation, each
  slide needs to be synchronized with audio stream.
• For example, while playing a movie the video
  stream needs to be synchronized with audio
  stream, referred as lip synchronization.

62
SYNCHRONIZATION

• Synchronization can be done by operating on data
  units.
• A process executes read and write operations an
  streams, ensuring that those operations adhere to
  specific timing and synchronization constraints.

63
SYNCHRONIZATION

• If multimedia middleware offers interfaces for
  controlling audio and video streams, applications
  can specify how to handle the incoming streams.

64
CONTENT DELIVERY NETWORKS

• Content Delivery Networks (CDN) evolved in 1998
  replicate contents over several mirrored web
  servers strategically placed at various locations.

65
CONTENT DELIVERY NETWORKS

• 1) Client requests content from www.discovery.com
  
• 2) discovery.com Web server makes a decision to
  provide only the basic contents (e.g. index page
  of the site)
• 3) Asks CDN provider to supply embedded objects
  (e.g. Navigation bar, banner ads, etc.)
• 4) Using a proprietary algorithm , CDN provider
  selects the replica server which is closest to
  the client
• 5) Selected replica server gets the embedded
  objects from the origin server, and serves the
  client.

66
CONTENT DELIVERY NETWORKS