Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

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

  • Print
  • Feedback
By and large, the majority of Internet traffic is unicast traffic, consisting of unique conversations between pairs of parties on the network, as shown in Figure 1 below. When you send email to someone, for example, a network connection is established between you and a mail exchanger, some commands are exchanged, and the body of your message is transmitted. When you visit a Web site, a network connection is established between you and the Web server, some commands are exchanged, and your computer receives the body of the page. In these scenarios, unicast makes sense; it is quite probable that your client and the remote server are engaging in a unique conversation on the network at that instant.

Figure 1. Unicast data transmission



Consider, however, the case of a streaming Internet radio station. In this case, the server will simultaneously transmit the same data to many different receivers. In other words, it will send the same packets of data multiple times, once for each connected client. It would potentially be much more efficient if the server could place a single packet onto the network and deliver that packet to all recipients without duplication. This scenario is obviously not practical, though; different clients would be on different networks, and each packet would have to trace a tortuous route to reach everyone along a single path.

Instead, consider a scenario, depicted in Figure 2, in which the server places a single packet onto the network and the network determines an optimal route to all clients, duplicating the packet only when necessary. The packet will thus travel outwards in a tree pattern, duplicating itself at branches in the network path from the server to all clients. This is IP multicast.

Figure 2. Multicast data transmission



This article is not going to show you how to create an Internet radio station; that would be far too complicated. Instead, the particular application that we will look at is a networked chat system. Here again, multicast will serve the goal of efficiency: when the system transmits a message to a chat room, rather than unicast it once to each client, the system can multicast it in a single operation to all clients, and the network will take care of optimal distribution.

Given a network that is capable of multicasting data, there are in fact two ways to design this chat system. One option, shown in Figure 3 below, would employ a central server to which clients unicast their messages and which then multicasts the messages back out. This is perhaps the most obvious redesign of a traditional Web-based chat system; however, it is not necessarily the best.

Figure 3. Server-based multicast



Multicast is in no way restricted to a traditional server-based architecture. At any given time, any member of the group is equally likely to take the duty of multicasting to all others. This capability lends itself to a much neater architecture for our chat system than the server-based system that I just described.

Consider, instead, a serverless peer-to-peer architecture, illustrated in Figure 4 below. In this architecture, members of the group multicast their messages directly to each other, simulating much more accurately a normal conversation among a group of people. This is the architecture that I will employ for this article. It should, of course, be noted that converting this to a server-based architecture is comparatively trivial, for those who are interested.

  • Print
  • Feedback

Resources