CS 475 Lecture 19 - uenics.evansville.eduuenics.evansville.edu/~hwang/f11-courses/cs475/lecture19-rpc-rtp.pdf · Tuesday, November 1 CS 475 Networks - Lecture 19 14 RPC Implementations

Tuesday, November 1 CS 475 Networks - Lecture 19 1

Lecture 19

Homework 6 posted, due next Tuesday. Questions?


In-class Exercises

Log on locally under Linux or log on remotely to csserver to answer the following questions: How do we send out-of-band data via TCP? (man send)

How do we receive out-of-band data? (man recv)

Which of the four TCP extensions described in class are supported under Linux? (man tcp)

What acronym is used for the TCP extension that helps to determine if the sequence number has wrapped around? What does this acronym stand for?

Is there a way to disable Nagle's algorithm so that segments are sent immediately? If so, how?


In-class Exercises

The Linux /proc pseudo-filesystem interface can be used to tune many of the TCP algorithms. Changing the parameters requires system administration privileges. Use cat to examine appropriate /proc file contents (man tcp) and determine the answers to the following: Is the optional SACK extension enabled? What is the default receive buffer size? Is the optional window scaling extension enabled? What is the default congestion control algorithm? Which

algorithms are available for use?


Outline

Chapter 5 - End-to-End Protocols

5.1 Simple Demultiplexer (UDP)

5.2 Reliable Byte Stream (TCP)

5.3 Remote Procedure Call (RPC)

5.4 Transport for Real-Time Applications (RTP)

5.5 Summary


Remote Procedure Call (RPC)

TCP and UDP provide byte stream channels. Another comm. pattern is the request/reply or message transaction paradigm.

The Remote Procedure Call (RPC) transport protocol more closely matches the needs of an application wanting to use request/reply than either UDP or TCP.


RPC Fundamentals

RPC is commonly used in building distributed systems. RPC allows a procedure to be either local or remote. An application calls the procedure as if it were local. The calling application blocks until the procedure returns.

Remote procedure calls are more complex than local procedure calls: Messages may be limited in size. They may also be

lost or reordered. Different computers may have different OSes,

architectures, and data representations.


RPC Fundamentals

RPC therefore involves two components: A protocol to manage message passing

between the client (caller) and server. Programming language and compiler (a stub

compiler) support to translate a procedure call on the client into a request message and translate the message into arguments on the server. The return value is handled similarly.


RPC Fundamentals


RPC Fundamentals

The term RPC refers to a type of protocol rather than a specific standard like TCP. There is no one dominant RPC protocol. We will look at several protocol design choices.

We will look at only the protocol related aspects of RPC. Translation of arguments into messages and vice versa is covered in Chapter 7.


RPC Fundamentals - Identifiers

RPC must provide a name space for identifying the procedure to be called.

The name space can be either flat or hierarchical. A flat name space requires central coordination to prevent assigning the same ID to different procedures. The ID can be carried in a single field in an RPC request.


RPC Fundamentals - Identifiers

An RPC protocol must also match a reply message to the corresponding request. This is done by including a message ID in both the request and reply.

A client boot ID may be used as part of the message ID in order to ensure that the correct match in the event that the client reboots with an outstanding request.


RPC Fundamentals - Overcoming Network Limitations

RPC can implement reliability using ACKs. Each side has a retransmit timer that causes the message to be resent in the event of a time out. A reply can be used as an implicit ACK.

Concurrent requests can be implemented using logical channels.


RPC Fundamentals - Overcoming Network Limitations

RPC reliability may implement at-most-once semantics in which there is a guarantee that no more than one request is delivered to the server.

Implementation of zero-or-more or idempotent semantics is simpler and sufficient for applications in which multiple requests have the same effect as one request.


RPC Implementations - SunRPC

SunRPC (aka ONC RPC) was developed by Sun as part of their Network File System (NFS). SunRPC can be implemented over several different transport protocols (SunRPC is also considered a transport protocol).

SunRPC uses a 32-bit program number and a 32-bit procedure number to identify a procedure (the NFS server has program ID 0x100003, the NFS read procedure has ID 6 while write has ID 8).



Different RPC servers are dynamically assigned TCP/UDP port numbers. The port mapper RPC server listens on well-known port 111. RPC clients can query the port mapper to determine the port number assigned to a program.

SunRPC does not implement its own reliability or fragmentation methods. It relies on the underlying protocol.



SunRPC request and reply headers



The XID field is a transaction ID that is unique to a request/reply pair. The Program and Procedure contain the corresponding 32-bit IDs. The Version field specifies a version of a program. Multiple versions of a program may be running on the server.

The variable length Credentials and Verifier fields are used by the client to authenticate itself to the server.


RPC Implementations - DCE-RPC

DCE-RPC is used in Microsoft's DCOM and ActiveX technologies. It is also used in CORBA, a standard for distributed object-oriented systems.

A typical DCE-RPC exchange is shown at right. If the server responds quickly enough, no Pings are sent.



DCE-RPC supports multiple logical channels known as activities and there is an ActivityID field in the header. A SequenceNum field distinguishes between calls in an activity. The sequence number is remembered at the server to ensure at-most-once semantics.

DCE-RPC supports very large messages and implements its own fragmentation scheme. Selective acknowledgment is used allowing only missing fragments to be retransmitted instead of the entire message.



Selective acknowledgment is shown at left. A WindowSize is used for flow-control.


Transport for Real-Time Apps (RTP)

Multimedia applications can be categorized as either streaming (audio, video streams) or interactive (VoIP, teleconferencing). Interactive applications have the strictest real-time requirements.

RTP can run over many lower level protocols, but is typically run on top of UDP. RTP is still considered a transport protocol.


Requirements

A multimedia protocol must allow applications to interoperate. One approach is to specify a particular audio and video coding scheme. RTP allows the sender to indicate which coding method it wants to use.

Our protocol must support playback synchronization to prevent jitter and provide means for audio and video synchronization.

The protocol must provide some means to indicate that a packet is lost, so that the receiver can take appropriate action.


Requirements

UDP does not provide congestion control and this is desirable in many real-time apps. The receiver must notify the sender that losses are occurring.

A real-time protocol should provide some indication of frame boundaries.

We should be able to associate a particular user (rather than just a host) with a stream.

Finally our protocol should use BW efficiently.


RTP Design

RTP supports a variety of applications. For each class (audio) it defines a profile and one or more formats.

A profile defines the fields in the RTP header. A format defines how the data after the header is to be interpreted (simple audio samples or an MPEG video stream).


RTP Design - Header Format

The first two bits specify the RTP version. The P bit indicates if padding is used. The last byte of padding contains the pad count.



The extension (X) bit indicates the presence of an extended header following the main header (rarely used).

The 4-bit CC field indicates the number of contributing sources.

The mark (M) bit denotes the start of a frame. The 7-bit payload type (PT) field indicates the type of payload data. The M and PT fields are precisely defined by the application profile.



The Sequence number is used at the receiver to detect missing or out-of-order packets. The application decides what to do in the case of a missing packet, not RTP.

The Timestamp allows samples to be played back at the appropriate interval and allows for synchronization between different streams. It is the number of ticks from the first sample.



The synch. source (SSRC) identifies a stream source. A node with multiple cameras would have a different ID for each camera.

The contributing source (CSRC) is used when several streams pass through a mixer (combining multiple audio streams). The SSRC is then the ID of the mixer.


Control Protocol

A control stream (RTCP) is associated with a data stream (RTP). RTCP (1) provides feedback on performance, (2) correlates and synchronizes different streams from a sender, (3) conveys info on the identity of the sender.

Multiple streams from a sender are associated with a canonical name (CNAME) that is assigned to the sender. Association with a CNAME allows different sources to be synchronized.


Control Protocol

RTCP defines several different packet types: sender reports contain transmission and

reception statistics receiver reports (from non-senders) contain

reception statistics. source descriptions carry CNAMEs. application specific packets


In-class Exercises

Run the command “rpcinfo -p” on Linux. Check the portmap and rpcinfo man pages. Refer to the rpc and xdr man pages for more

information. Start homework.

Documents

CS 475 Lecture 19 - uenics.evansville.eduuenics.evansville.edu/~hwang/f11-courses/cs475/lecture19-rpc-rtp.pdf · Tuesday, November 1 CS 475 Networks - Lecture 19 14 RPC Implementations