Serve clients’ specific protocol requirements with Brazil, Part 4

JRMS examples

You can find documentation for the JRMS APIs online. (See Resources for a link.)

Brazil technology and JRMS

Real-time weather data from the one-wire weather station is one of the data sources for this Brazil series. Weather data is a particularly good candidate for multicast because there is no shortage of it, the data is the same for everyone, and users want it constantly updated. In fact, many telemetry applications could benefit from the use of multicast channels.

The JRMS API is easy to use, so adding support for both TRAM and LRMP to Brazil is not complicated.

The weather handler (see Resources) simply creates a JRMS channel and uses a thread with requests to a JRMS weather object, which is called when new weather data becomes available. The weather object serializes the weather data and sends it out the channel. Clients that have posted a read on the channel receive the data and display it. The following code segment in the Weatherhandler.java file creates the channel:

        try {
            Class c = Class.forName("com.sun.multicast.allocation.Address");
            dbg("JRMS starting");
            jrms = new WeatherJRMSServer();
            jrms.createChannel(jrmsIP, jrmsPort);
            server.log(Server.LOG_WARNING, null, prefix + ". JRMS available");
        } catch (ClassNotFoundException notFound) {
            notFound.printStackTrace();
            server.log(Server.LOG_WARNING, null,
                       prefix + ". JRMS not available");
            return (true);
        } catch (Exception e) {
            server.log(Server.LOG_WARNING, null,
                       prefix + ". JRMS not started " + e.getMessage());
            return (false);
        }

First, make sure that you have the required JRMS class files. The WeatherHandler starts up several different services so that if the JRMS class library is unavailable, the other services still operate. The WeatherJRMSServer object contains methods for creating a channel and preparing data for transmission. The jrmsIP and jrmsPort variables identify the multicast IP address and the port number to use for communication. Clients will look for data at this pair of address ports. For the example above, the values of 224.10.10.10 and 4343 are used. Multicast addresses are allocated from certain parts of the IP address space. (See Resources for more information.)

Once you start the service and create a channel using the aforementioned technique, you are ready to write some data to the channel.

The following code segment writes a property object to multicast clients:

ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream(bos);
os.writeObject(p);
os.flush();
bos.close();
if (jrms != null) {
    if (!jrms.sendDataPacket(bos.toByteArray())) {
        server.log(Server.LOG_DIAGNOSTIC, null, "No members");
    }
}

The above code segment is in the thread that waits for new data from the WeatherStation. The segment checks for a server object; if one exists, the code segment serializes a property object that contains properties like weather.sample.temperature=105. The serialized property object is written to a byte stream. The sendDataPacket() method then transmits those bytes as a multicast packet.

Server

The server object that transmits weather data to JRMS clients supports either TRAM or LRMP on the created channel; you can use both on a port at one time. (See Resources for the annotated source for the server.) The two methods in WeatherJRMSServer create a channel and send data over it: public void createChannel(String address, int port) and public boolean sendDataPacket(byte data[]).

The createChannel() method supports either TRAM or LRMP. Use TRAM when you have a single sender and many receivers.

LRMP is better for smaller groups with more than one sender. The code to set up a sender using LRMP is:

lrmp = (LRMPTransportProfile) new LRMPTransportProfile(mcastAddress, port);
lrmp.setTTL((byte) 20);
ms = lrmp.createRMPacketSocket(TransportProfile.SEND_RECEIVE);

where ms is of type RMPacketSocket.

The code to send a packet is simple:

 
sendPacket = new DatagramPacket(data, data.length, mcastAddress, port);
ms.send(sendPacket); 

Client as a Java application

The client application provides an easy-to-use GUI that allows users to select a particular weather station within a channel. The UI provides the following interface:

The above application lets users easily select different sources of weather information from the UI. Developers should also be able to provide historical, graphical, and analytical views of the data. For example, application functionality could be added to provide client-side processing of multicast data, which would offer more information. Or additional data, such as running averages, could be sent on the channel for all users.

JRMS (using LRMP) supports multiple senders and receivers. So all the senders could register to send weather packets with the description field and the corresponding latitude/longitude (LAT/LON) to ensure uniqueness. (For more information on LAT/LON, see Resources.) Receivers could then connect to these channels and select a sample. Over time, of course, channels could be developed that support specific areas around a central point. For example, a channel name could be a LAT/LON with a radius indicating what LATs/LONs the channel encompasses.

See Resources to download the source code for the client.

The following code segments demonstrate how to locate a channel and read data from it. The first segment creates a client using LRMP:

tp = new LRMPTransportProfile(InetAddress.getByName(address), port); 
ms = tp.createRMPacketSocket(TransportProfile.RECEIVE); 

The following code segment reads the data sent by the transmitter:

byte inPacket[] = recvPacket.getData();
ByteArrayInputStream bis = new ByteArrayInputStream(inPacket);
 ObjectInputStream p = new ObjectInputStream(bis);
Properties props = (Properties) p.readObject(); 

A developer can read the data using recvPacket. The transmitter has sent the data as a serialized property object. The received bytes are then used as input to an ObjectInputStream so that the Property object can be reconstituted. The transport layer has no knowledge of the data being transmitted in this application, so you create a Property object from the received bytes. The rest of the program deals with program startup and shutdown, as well as a minimal user interface.

Run the JRMS code as an applet

Certain applications benefit from the use of an applet model of distribution, rather than an application model. The applet model allows users to dynamically download small portions of functionality, so installation is not required. However, since JRMS and many other APIs require security privileges and supporting class libraries, sometimes it makes sense to install the classfiles as a general resource for all browser-based applications. The JRMS weather client can be modified so that browser-based applications can send and receive multicast data. Recently, Sun developed additional technology to further simplify this process. (See Web Start in Resources.) Developers can use JRMS in applets by following these steps:

• Provide the correct functionality in start(), stop(), and init()
• Determine how jar files will be distributed; consider using Web Start
• Provide directions for users to install the Java Plug-in on IE and Netscape
• Determine security requirements, since a multicast-aware applet will require additional privileges

Conclusion

When using JRMS, you must first make sure that users have access to multicast packets. The easiest way to test that is to ensure that users can run a simple example using their protocol of choice, LRMP or TRAM. Do not assume that multicast will work on corporate intranets; the routers must be configured to support multicast. Many IT managers who are responsible for network infrastructures do not like to support multicast. To justify the use of JRMS in a corporate Internet environment, you may have to show IT managers the benefit of designing the application with and without multicast ability. Getting the entire Internet to support multicast is a much larger issue. Occasionally an ISP or ASP will support multicast technology, but you must make sure that all your users have similar abilities.

In these four articles, I have demonstrated how Brazil can easily support new protocols and interface them to existing protocols with minimal user effort. You can control startup, shutdown, and management of these services by providing URLs for the specific abilities desired.

For example, in the management area, JRMS provides statistics in the RMStatistics object, which TRAM implements as TRAMStats. These statistics can be made available as properties, which can be processed using the Brazil Scripting Language to create custom HTML reports.

We need a technology to support applications in the collaborative computing areas with streaming multimedia and real-time data delivery. These applications inherently require multipoint communication between one or more senders and many receivers. JRMS provides an API that allows developers to use multicast to develop multicast-aware applications. The fact that JRMS is written in Java provides further investment protection, as networks and bandwidth increase in devices, like cell phones, and expensive telemetry devices, like TINI boards.

Acknowledgements

I would like to thank Miriam Kadansky, Joe Provino, and Dah Ming Chiu of the JRMS team at Sun Microsystems Laboratories for reviewing this article and providing such a well-documented API with simple and complex examples.