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(...);

Firewalls

On the homework, you are asked to look at the performance of TCP over a small network.
Another important issue in configuring a network is setting up and maintaining a firewall.
A firewall is an network appliance or application that controls access to a network, or a host on a network, based on inspecting the network traffic flowing through it.
There are two common styles of firewall, those that look at the packet headers and determine if the packet should be allowed; and those that look at the target application of the packet and determine if it should be allowed.
The firewalls built-in to Windows and Mac OSX are mainly of the latter type and usually have a relatively easy to use GUI interface. The Windows firewall seems to be more configurable.
We will look at the packet-based firewalls which tend to be a little more sophisticated and are often run from the command line. (Although there are GUI front-ends such as Water-roof).
Mac OSX come with one such tool called ipfw; Linux has iptables which is based off of the earlier ipchains.
Both of these support both static and dynamic rules. They also support the ability to do traffic shaping.

Running a Firewall

To use ipfw and iptables, you usually need to run commands as either root or use sudo.
To see all of the rules that are currently being used by your firewall you can do a command like:
```
ipfw list
```
or
```
iptables --list
```

To add a basic rule in ipfw you might do:

ipfw add 1000 allow ip from 10.0.0.0/8 to any

or for iptables like:

iptables -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -j ACCEPT

The command to delete a rule for ipfw is delete followed by the number or delete followed by the whole rule; similarly, for iptables you can use the option -D or --delete.
Notice for both we specify the protocol. In the ipfw example, it was ip, and in the iptables example it was tcp. You could also say udp.
For IPFW, we could have said deny rather than allow; similarly we could say DROP rather than accept for iptables.
-s is for source -d is for destination address in iptables.
For ipfw you can use the keywords in or out at the end of the rule. You can add a list of ports after the the addresses.
Typically, one keeps ones rules in a file like /etc/rc.firewall or /etc/firewallrules so they are read at start-up.

Transport Protocols for Real-Time Applications

An application is called real-time if it has a strong requirement for the timely delivery of information.
For example, Voice over IP, video, audio conferencing, etc. are real-time applications.
Streaming applications such as internet radio or YouTube, lack human-to-human interaction, and so often place less stringent requirements on the underlying protocols.
Nevertheless, they share enough commonalities with real-time applications to warrant common protocols for both types of applications.
One protocol for doing this is called RTP which derived many of its features from the vat application (a videoconferencing tool).
RTP can run over many lower-layer protocols but commonly runs over UDP.

Requirements of Real-Time Applications

The most basic requirement for a general-purpose multimedia protocol is to allow similar applications to interoperate with each other.
For example, two independently implemented audio-conferencing tools should be able to interoperate.
To handle this the protocol should provide a means to negotiate the kind of compression, encoding, etc of the audio data being sent. (Similarly, the codec if video conferencing was being done).
Another important requirement for RTP is to enable the recipient of stream data to determine the timing relationship among the received data.
The received data needs to be placed into a playback buffer to smooth things out like jitter.
If a conference is being done, then synchronization of several streams needs to be done. Also, for video one needs to probably synchronize separate audio and video streams.
The application must also be able to handle packet loss in a reasonable manner.
RTP needs to be able to handle framing. For instance, know when data that has arrived constitutes a displayable unit.
Finally, RTP needs to have some way of naming senders and receivers that is more friendly than IP addresses.

RTP Details

RTP was developed at the IETF and was first published in 1996.
It is commonly used to do VoIP and Video-teleconferencing.
It is actually a pair of protocols: RTP and the Real-time Transport Control Protocol (RTCP)
For each application (audio, video, etc) which makes use of RTP, a profile and one or more formats are defined.
The profile provides a range of information used to ensure a common understanding of the fields in the RTP header for that application class.
The format specification explains how the data that follows the RTP header is to be interpreted.
For instance, for audio the format might say that each byte that follows is a sequence of sound samples.
This use of profiles and formats is an example of application level framing.

Header Format

V=2 | P | X | CC | M | PT | Sequence Number

Timestamp

Synchronization source (SSRC) identifier

Contributing source (CSRC) identifiers
...

Extension Header

RTP Payload

The first 12 bytes of the header are always present, CSRCs and extensions may or may not be present
The first two bits are a version identifier which is currently version 2.
P is a "padding" bit which is set if the RTP payload needed to be padded to some size, for instance, because of the requirements of an encryption algorithm.
The extension bit X is used to indicate the presence of an extension header; the 4 bit CC field is used to indicate the number of CSRCs.
M is used for framing.
PT is a 7 bit field that indicates the payload type. Using it an application could switch from one kind of coding scheme to a different one.
The sequence number is used to detect missing or mis-ordered packets. RTP does not do anything when it detects a packet loss (the app decides what to do).
The timestamp is used to enable playback from different portions of the stream and to synchronize tracks if more that one stream is in use (say audio and video).
Timestamps represent the time at which the first sample in the packet was generated.
The synchronizing source (SSRC) is a 32-bit number that uniquely identifies a single source of an RTP stream. In a multimedia conference each sender picks a random SSRC and is expected to resolve conflicts in case of a collision.
The contributing source (CSRC) is only used when the RTP streams pass through a "mixer" of serveral other sources. In which case the mixer will be the SSRC and the other contributers are listed in the CSRC.

Control Protocol

RTCP provides three main functions
- Feedback on the performance of the application and the network
- A way to correlate and synchronize different media streams that have come from the same sender.
- A way to convey the identify of a sender for display on a user interface.
The first function may be useful for rate-adaptive applications.
The second function entails both being able to follow the name of a stream if its SSRC has to change because of a collision (using CNAMEs), and also synchronizing the clocks of different media that may be involved in the communication.

Java RMI, Firewalls, RTP

Outline

Introduction