Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Multicast the chatwaves

Use IP multicast along with custom stream classes to implement a cool, yet simple, peer-to-peer networked chat system

By Merlin Hughes, JavaWorld.com, 10/20/99

Page 2 of 4

Figure 4. Peer-to-peer multicast

I'm not planning on going into great depth here about the internals of multicast; others have done more than I could ever hope to. If you'd like more multicast details, I've included some helpful links in the Resources section at the end of this article. However, I do have to present two big caveats about multicast up front: multicasting is, by itself, neither reliable nor pervasive.

If you multicast some data, it may be lost or delivered out of order; this represents multicasting's main problem with reliability. Also, losses and misordering may vary by recipient, which means that some recipients may receive the data as intended while others may experience various losses. It is possible to layer protocols that add reliability on top of raw multicast; the Java shared data toolkit employs one such protocol, LRMP (Lightweight Reliable Multicast Protocol). However, without the use of such a higher-level protocol, applications have to be able to tolerate data loss.

The second problem, multicasting's lack of pervasiveness, is due to the fact that multicast is not deployed on the Internet at large. There are islands (for example, Ethernet wires, corporations, university campuses, and various ISPs) that support multicast, and there are technologies (the MBone, for example, or multicast-enabled routers) that can link multicast-enabled islands across the Internet. But, by and large, random machines on the Internet cannot communicate using IP multicast. As a result, multicast is currently suitable only for controlled environments.

I'm also going to skimp on a detailed introduction to Java's specific multicast-related classes. For the purposes of this article, however, I've included a brief sidebar on them to get you started.

Design

To keep things manageable, our chat system will be purely text-based: clients will communicate among themselves using simple strings of text. For universality, of course, we will use Java's character streams to support the characters of any (supported) language. Also, as stated earlier, our chat system will be purely peer-to-peer; unlike most traditional client/server chat systems, there will be no server. All clients are created equal in the eyes of this system.

Multicast groups

Some questions naturally follow from the use of this architecture. How, using the multicast model, do we define a chat room? And how do interested persons gather there to chat? In a client-server system, you name the server, port, and, if your protocol demands it, a room. In this system, however, there is no server to identify. In the world of multicast, the same idea of a central gathering point is implemented with the concept of a multicast group. Under the current version of IP, there are 268 million multicast groups, identified by the IP addresses 224.0.0.0 through 239.255.255.255. When you join a particular group, you announce to the underlying network infrastructure that you are interested in messages sent to that group. The network will then attempt to ensure that you receive all messages sent to that group across the entire multicast-enabled archipelago to which you are connected. To send a message to a group, simply drop it onto the network, addressed to the appropriate group. The network will then attempt to deliver your message to all members of that group. Indeed, you do not even need to be a member of a group to send messages to it.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.