Outline

• TCP Record Boundaries
• TCP Extensions
• Quiz
• RPC
• RMI

Record Boundaries

• TCP is a byte-stream protocol. The sender sends bytes which happen to be put into segments.
• For instance, the sender might send 10 bytes in the first segment 20 in the next.
• Usually, the application at the receiver is only aware that there are bytes it can read from the receiving TCP layer, and not the segment boundaries. i.e., for the example above, the receiving application would not know the 10th byte was in one segment and the 11th in the next.
• TCP does support two features that can be used to inform the receiver of a message boundary: the URG flag and the push operation.
• The URG flag and the UrgPtr in the TCP header were originally supposed to be used to send "out of band data"; that is, to send things like commands to interrupt an operation already underway.
• This data would be sent to the receiving process as soon as it arrived, even if this meant delivering it before data with an earlier sequence number.
• This original use of the URG flag was not used so often; and over time, the URG pointer switched to be used to signify special data, such as a record marker.
• Similarly, the PUSH flag can also be used to flush data from the receiving buffer to a receiving process that supports PUSH, so setting this flag can also be used to indicate record boundaries.

TCP Extensions

• We have mentioned a few times that there are extensions to TCP to mitigate against problems in the original design as networks get faster.
• These extensions are realized as options that can be added to the end of the TCP header.
• Since they are designed to be optional and since they are at the end of header, if a host does not understand these options then it can still communicate using usual TCP.
• The first common extension is used to improve TCP's timeout mechanism by including a 32 bit timestamp into the segments header.
• The receiver echoes this back to the sender when it acknowledges segments. The sender subtracts the timestamp from the current time to estimate the RTT.
• A second use for the timestamp is to extend the SequenceNum. If this is used, TCP accepts or rejects a segment based on the 64 bits consisting of the timestamp in the high 32 bits and the SequenceNum in the low 32 bits.
• Another extension to TCP is to use the options to define a scaling factor for the two-byte AdvertisedWindow. i.e., rather than the AdvertisedWindow saying the window in units of bytes it says it in units of some number of bytes given by the scaling factor.
• A last common extension is to use the options field to do selective acknowledgements of data received but not contiguous to data that had been previously received.
• This enables the sender to resend only the just the segments that have not arrived.

Remote Procedure Call

• TCP uses a byte-oriented connection.
• Another common communication paradigm used by applications programs is the request/reply paradigm.
• A transport protocol that supports request/reply is more than simply UDP going in one direction followed by a UDP message going in the other direction.
• Besides needing to correctly identify processes on the remote host, such a protocol needs to correlate requests with responses.
• We next look at Remote Procedure Call transport protocols which are designed to give this facility.

RPC Fundamentals

• RPC is based on the semantics of a local procedure call -- the application programs makes a call into a procedure without regard to whether it is local or remote -- and blocks until the call returns.
• When the procedure being called is actually a method of a remote object in an object-oriented language RPC is known as Remote Method Invocation (RMI).
• There are two main ways that RPC is more complicated than local procedure calls:
  1. The network might do things like limit message sizes, or might lose or reorder messages.
  2. The computer on the calling side and called processes may have significantly different architectures and data representation formats.
• Thus, a complete RPC mechanism involves two main components:
  1. A protocol to manage messages sent between the client and the server processes that deals with the underlying network issues that might cause problems.
  2. Programming language and compiler support to package the arguments into a request message on the client and then to translate this message back into the arguments on the server machine. Likewise, the return values needs to be handled. This mechanism is often called a stub compiler.

Quiz

Which of the following is true?

1. Even if the advertised window goes to 0, a sender using TCP will still send segments periodically.
2. When a server sees a SYN+ACK, it thinks a client's connections has been established.
3. Only the server will ever send a TCP FIN/ACK

The RPC Protocol

• The RPC protocol needs to:
  • Provide a name space for uniquely identifying the procedure to be called
  • Match each reply message to the corresponding request message.
• Common choices for the namespace problem are to either make it flat or to make it hierarchical.
• In the first choice an unstructured identifier like an integer ID would be carried in a single field in an RPC message.
• Some kind of central coordination would be needed to avoid assigning the same number to different procedures.
• In the second choice, some kind of analog to a file path in a filesystem is used.
• To match a reply with a corresponding request, message ID's are used. A reply should use the same message ID as the request.
• To make the RPC transaction appear like a local procedure call, the caller is blocked until the reply message is received.
• To ensure that a message ID does not get re-used because a machine went down or something, the protocol also uses a boot ID which gets incremented each time the machine is booted.

Overcoming Network Limitations

• RPC protocols often perform additional functions to deal with the fact that networks are not perfect channels. Two of these functions are: Provide reliable message delivery, and support large message sizes through fragmentation and reassembly.
• RPC might need to do the first as it is often implemented on top of IP or UDP which do not provide for reliable delivery.
• One way to do this is to have the server acknowledge requests (then start running the procedure), and the client acknowledge replies.
• The client and the server need to save a copy of their messages until they see the ACK.
• Each side also sets and uses a RETRANSMIT timer to resend the message if it is delayed too long.
• As you might guess, the server can use the reply message to implicitly acknowledge the request.
• We could also use a subsequent request to acknowledge a previous reply.
• To allow for greater flexibility, RPC often makes use of an abstraction known as a channel.
• The idea is that within a channel, request/reply transactions are sequential -- there can be only one transaction active on a given channel at a given time. The protocol then allows that there can be multiple channels.
• If this is used, in addition, to a message ID one also has a channel ID.
• To distinguish between slow versus dead server, the client periodically sends messages to a server that hasn't sent a reply asking if it is still calculating.

Java Remote Method Invocation

• Java Remote Method Invocation is a simplified mechanism for objects to communicate with each other over the web.
• It is a stripped-down version of a programming language non-specific protocol known as CORBA.
• The key participants in the RMI architecture are:
  • The Server: -- an object that provides services to objects residing on remote hosts
  • Service Contract: -- An interface that defines the services provided by the server
  • Client: -- an object that uses the services provided by the server
  • Stub: -- an object that resides on the same host as the client and serves as a proxy for the remote server
  • Skeleton: -- an object that resides on the same host as the server and serves as a proxy for the client.

Using RMI

• Get the rmi registry running on the server: rmiregistry&
• Define an interface for the remote object.

  public interface Contract extends Remote 
  {//Remote is in java.rmi 
  public void method1(...) throws 
  RemoteException; 
  //other methods 
  } 
  

• Implement the contract in some class on the server:

  public class ServiceProvider extends UnicastRemoteObject 
  implements Contract {/*code*/}
  

• ...

More Using RMI

• Create an instance of the server and register that server to the RMI registry:

  Contract server = new ServiceProvider(...); 
  Naming.rebind(name, server); 
  

• Generate the stub and skeleton classes, using the rmi compiler:

  rmic  ServiceProvider 
  

  This generates two files ServiceProvider_stub.class and ServiceProvider_Skel.class. The former should be on the client machine the latter on the server. These class files actually handle the communication over the internet.
• Develop a client that uses the services provided by the Contract interface:

  Remote remoteObj = Naming.lookup(name); 
   /*looking up rmi names is done with a URL like rmi://host:port/name where 
  name is the name of the service on the server */ 
  Contract serverObj = (Contract)remoteObj; 
  ...
  serverObj.method1(...);