Communication

1
Communication

• Chapter 2

2
Communication

• Layered protocols
• Usual networking approach (client/server)
• Remote Procedure Call (RPC)
• Hide message passing details (client/server)
• Remote Method Invocation (RMI)
• Improved RPC (client/server)

3
Communication

• Message-Oriented Communications
• Message Passing ? Low level, efficient
• Message-Oriented Middleware (MOM) ? Non
  client/server
• Streams
• Continuous flow subject to timing constraints

4
Layered Protocols

• OSI reference model
• Each layer provides service to layer above
• Implementation of service can change

5
Layer Services

• Transport layer
• Logical connection between hosts
• Reliable communication between hosts
• Network layer
• Route packet thru network
• Data link layer
• Get packet over each hop
• Physical layer
• Put the bits on the wire

6
Layered Protocols

• Layered message
• Add headers when msg sent (down protocol stack)
• Peel the onion when msg received (up the protocol
  stack)

7
Data Link Layer

• Communication at data link layer
• Above, A tries to send msgs 0 and 1 to B

8
Network Layer

• On a LAN
• Have a shared media
• Put the packet out, recipient picks it up
• On a WAN
• Have point-to-point communication
• Many possible routes
• Finding best route is difficult

9
Transport Layer

• UDP for unreliable delivery
• Better performance possible with UDP
• TCP for reliable delivery
• May be easier to build app with TCP

10
Client-Server TCP
Transactional TCP
Normal TCP
11
Middleware Protocols

• Reference model for middleware based distributed
  communication

12
What is Middleware?

• Logically at application layer
• General purpose protocols
• Independent of an application
• Well distinguish between
• High level application and
• Middleware

13
Middleware Example

• Often, must authenticate users
• Require users prove identity
• Spse you build authentication system
• Any app can use your auth system
• Your authentication application
• Is at application layer in OSI
• Is also at middleware layer in our view

14
Middleware

• Remainder of this chapter
• 4 middleware communication services
• RPC
• RMI
• Message oriented communication
• Streaming

15
Remote Procedure Call

• Distributed systems can be built on explicit
  message passing
• For example, send and receive
• Whats wrong with this approach?
• Its not transparent to users
• Why should we care?
• Recall that transparency is one of primary goals
  in distributed systems

16
Remote Procedure Call

• RPC is a simple idea
• Make remote operation seem like a (local)
  procedure call
• All the great things are simple ? Winston
  Churchill
• Much better transparency compared to primitive
  message passing
• Can we make remote operation seem local?

17
Conventional Procedure Call

• Consider C function count read(fd, buf, bytes)

1. Stack before call to read
2. Stack while called procedure is active

18
Parameter Passing

• Consider again
• C function count read(fd, buf, bytes)
• In C, parameters can be
• Passed by value bytes
• Passed by reference the array buf
• Usually not important whether pass by value or
  pass by reference is used
• But its a big deal in RPC!
• Since procedure will execute at remote location

19
RPC between Client/Server

• We say that this is synchronous
• Since client waits for result

20
Stubs

• On client side, stub marshalls parameters and
  send to server
• Pack parameters into message(s)
• On server side, stub converts to local procedure
  call, sends back results
• Stubs increase transparency

21
Passing Value Parameters

• Suppose add(i,j) returns i j
• Remote computation via RPC

22
Client Stub

1. Procedure
2. Stub marshalls params

23
Steps in RPC

1. Client procedure calls client stub in normal way
2. Client stub builds message, calls local OS
3. Client's OS sends message to remote OS
4. Remote OS gives message to server stub
5. Server stub unpacks parameters, calls server
6. Server does work, returns result to the stub
7. Server stub packs it in message, calls local OS
8. Server's OS sends message to client's OS
9. Client's OS gives message to client stub
10. Stub unpacks result, returns to client

24
Additional RPC Topics

• Doors
• Caller and sender on same machine
• Asynchronous RPC
• Client does something while server works on
  procedure
• DCE RPC
• Specific implementation of RPC

25
Doors

• If client and server on same machine
• Use interprocess communication (IPC)
• More efficient than network protocols

26
The Doors

• Doors are not to be confused with The Doors

27
Asynchronous RPC

1. Usual (synchronous) RPC
2. Asynchronous RPC

28
Asynchronous RPC

• Client and server interact via two asynchronous
  RPCs
• More efficient, if applicable

29
DCE RPC

• Distributed Computing Environment (DCE)
• Read this section
• A couple of interesting items
• DCE semantic options
• At-most-once ? no call done more than once, even
  if system crash
• Idempotent ? calls can be repeated multiple times
  (e.g., read)

30
DCE RPC

• Client-to-server binding in DCE
• Note directory service

31
RMI

• Remote Method Invocation
• Distributed objects
• Objects hide internals
• Provides transparency
• Also desirable in distributed systems
• RMI can increase transparency compared to RPC
• Chapter 10 has real systems

32
Objects

• Object encapsulates data, the state
• Object encapsulated methods, operations on the
  data
• Methods are made available thru well-defined
  interfaces
• In distributed environment
• Interface can be on one machine and
• Corresponding object on another machine

33
Distributed Objects

• Interface on client
• Proxy ? like client stub in RPC
• Object on server
• Skeleton ? like server stub in RPC

34
Compile-time vs Runtime

• Compile-time objects
• Objects analogous to those in Java, C
• Pluses easy to implement
• Minuses depends on specific language
• Runtime objects
• Implementation is open, use adapter (wrapper) to
  hide implementation
• Plus and minus opposite of those above

35
RMI and Parameter Passing

• Makes sense to treat local and remote objects
  differently
• Lots of overhead to remote objects
• Pass by reference gets complicated

36
Java RMI

• Distributed objects are an integral part of Java
• Aims for high degree of transparency
• For example client proxy has same interface as
  remote object
• There are subtle differences between local and
  remote objects

37
Java RMI

• Cloning
• Cloning a local object results in exact copy
• Only server can clone remote object
• In Java, proxies not cloned
• So must bind (again) to cloned object
• Can declare method to be synchronized
• Ensures access to data is serialized
• Blocking
• Clients blocked

38
Java RMI

• Read the details
• A preview of Chapter 5
• Spse multiple clients want to access a method on
  server (method is synchronized)
• Block all but one client ? lots of overhead
• Block at the server ? what if client crashes?
• Java restricts blocking to proxies
• Simplifies things
• But then cant prevent simultaneous access of
  remote objects simply by synchronized

39
Message-Oriented Comm.

• RPC and RMI enhance transparency
• But RPC and RMI are inherently synchronous
• Consider an email system where
• Messages stored on email servers when in transit
  and before read
• Stored locally after read
• Example of persistent communication

40
Message-Oriented Comm.

• In email example
• Sender need not continue executing after sending
  msg
• Receiver need not be executing when msg sent
• Comparable to the Pony Express!
• The more things change, the more they stay the
  same

41
Pony Express

• Persistent comm and the Pony Express

42
Transient and Asynchronous

• Transient
• Msg is stored only as long as sender and receiver
  are alive
• If msg cant be delivered, discard it
• Asynchronous
• Sender does not wait for response before
  continuing
• Recall persistent and synchronous
• Four possible combinations

43
Examples

• Transient asynchronous
• UDP
• Transient synchronous
• Synchronous RPC
• Persistent asynchronous
• email
• Persistent synchronous
• Msg can only be stored at receiving host

44
Persistence and Synchronicity

1. Persistent asynchronous communication
2. Persistent synchronous communication

45
Persistence and Synchronicity

1. Transient asynchronous communication
2. Receipt-based transient synchronous communication

46
Persistence and Synchronicity

1. Delivery-based transient synchronous
   communication at message delivery
2. Response-based transient synchronous communication

47
Message-Oriented Comm.

• Message-oriented systems take transient
  asynchronous as baseline
• Like UDP
• But persistence sometimes needed
• Especially if geographically distributed
• Network or process failures likely
• Message passing like transport layer

48
Message-Oriented Comm.

• Transient
• Berkeley sockets
• Message Passing Interface (MPI)
• Persistent
• Message queuing model, MOM
• Message brokers

49
Berkeley Sockets
Primitive Meaning
Socket Create a new communication endpoint
Bind Attach a local address to a socket
Listen Announce willingness to accept connections
Accept Block caller until a connection request arrives
Connect Actively attempt to establish a connection
Send Send some data over the connection
Receive Receive some data over the connection
Close Release the connection

• Socket primitives for TCP/IP

50
Berkeley Sockets

• Connection-oriented communication pattern using
  sockets
• Note synchronization point

51
Message-Passing Interface (MPI)
Primitive Meaning
MPI_bsend Append outgoing message to a local send buffer
MPI_send Send a message and wait until copied to local or remote buffer
MPI_ssend Send a message and wait until receipt starts
MPI_sendrecv Send a message and wait for reply
MPI_isend Pass reference to outgoing message, and continue
MPI_issend Pass reference to outgoing message, and wait until receipt starts
MPI_recv Receive a message block if there are none
MPI_irecv Check if there is an incoming message, but do not block

• A few (of the many) MPI primitives
• Emphasis here is on efficiency
• Big parallel machines use MPI

52
Message-Passing Interface (MPI)
Primitive Meaning
MPI_bsend Append outgoing message to a local send buffer
MPI_send Send a message and wait until copied to local or remote buffer
MPI_ssend Send a message and wait until receipt starts
MPI_sendrecv Send a message and wait for reply
MPI_isend Pass reference to outgoing message, and continue
MPI_issend Pass reference to outgoing message, and wait until receipt starts
MPI_recv Receive a message block if there are none
MPI_irecv Check if there is an incoming message, but do not block

• Transient asynchronous MPI_bsend
• Transient synchronous MPI_ssend
• Stronger form of synchronous MPI_sendrecv
• Many more possibilities (read the book)

53
Message Queuing

• Persistent
• Message-Queuing Systems or MOM
• Insert msgs into queues
• Delivered via a series of servers
• Can be delivered even if server down
• No guarantee msg will be delivered
• No assurance msg will be read, etc.
• For systems where communications takes minutes
  instead of milliseconds

54
Message-Queuing Model

• Loosely-coupled communications using queues

55
Message-Queuing Model
Primitive Meaning
Put Append a message to a specified queue
Get Block until the specified queue is nonempty, and remove the first message
Poll Check a specified queue for messages, and remove the first. Never block.
Notify Install a handler to be called when a message is put into the specified queue.

• Simple interface to message-queuing system
• Put is non-blocking
• Get blocks only if queue is empty
• Poll is non-blocking form of Get

56
Message-Queuing System

• Addressing in message-queuing system

57
Message-Queuing System

• Routing in message-queuing system

58
Message Brokers

• Message broker in message-queuing system
• Translates between msg formats

59
Example IBM MQSeries

• Read it

60
Streams

• Other methods based on more-or-less independent
  units of data
• Timing does not affect correctness
• In multimedia, timing is critical
• Audio and video
• Can tolerate loss, but not jitter
• Temporal relationship is important

61
Stream Transmission Modes

• Asynchronous transmission mode
• Data sent one after another
• No other timing constraints
• Synchronous transmission mode
• Max end-to-end delay for each unit
• Isochronous transmission mode
• Max and min end-to-end delay

62
Stream

• Stream from process to process
• Stream can be viewed as a virtual connection
  between source and sink

63
Stream

• Stream sent directly between two devices

64
Stream

• Multicasting a stream
• Different requirements for receivers?

65
Specifying QoS
Characteristics of the Input Service Required
Maximum data unit size (bytes) Token bucket rate (bytes/sec) Toke bucket size (bytes) Maximum transmission rate (bytes/sec) Loss sensitivity (bytes) Loss interval (?sec) Burst loss sensitivity (data units) Minimum delay noticed (?sec) Maximum delay variation (?sec) Quality of guarantee

• A flow specification

66
Specifying QoS

• A token bucket algorithm
• Dont want bucket to be empty of overflowing
• Then can feed out at precise time intervals

67
Setting Up a Stream

• RSVP for resource reservation
• Purpose is to try to insure QoS
• Highly dependent on data link layer

68
Synchronization

• Explicit synchronization for data units
• Read and write incoming stream units
• App is responsible for sync., only low-level
  utilities

69
Synchronization

• Synchronization supported by high-level
  interfaces
• A middleware approach

70
Summary

• Communication is a fundamental issue in
  distributed systems
• Networking overview
• RPC
• Goal is transparency
• RMI
• Transparency and objects
• RPC and RMI are synchronous

71
Summary

• Recall
• Synchronous ? block until msg delivered (or until
  response received)
• Asynchronous ? sender continues immediately after
  sending
• Persistent ? msg stored until delivered
• Transient ? msg delivered now or never

72
Summary

• Message-Oriented Communication
• Message passing
• For transient asynchronous (MPI)
• Good for big parallel machines
• Message-oriented middleware (MOM)
• Designed for persistent asynchronousStreams
• Streams
• Primarily for video and audio
• Temporal relationship is critical