Multicast the chatwaves - JavaWorld October 1999
Tutorial Details:
Multicast the chatwaves
Multicast the chatwaves
By: By Merlin Hughes
Use IP multicast along with custom stream classes to implement a cool, yet simple, peer-to-peer networked chat system
y 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.
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.
So, how do you know which group is yours? Well, that's a big picture issue. You can apply to the Internet Architecture and Naming Authority (IANA), if you want; however, it's doubtful that IANA would assign you a group number just for a chat room. More often, if the group will be restricted to just your organization, you can ask your system administrator to assign one of the 16 million private-use group numbers (those beginning with 239).
To make administration easier, multicast supports a special time-to-live feature whereby you can limit how far messages will travel. You can restrict a chat group to just your department intranet, for instance, or perhaps to your local Ethernet wire. There are two aspects to this. First, you must configure the routers and tunnels of your network appropriately. Usually, this is performed by your system administrator. Second, you must choose an appropriate time-to-live for the messages that you send; the value will depend on your local network configuration. A time-to-live of 1 will restrict packets to your local Ethernet wire, while 63 typically restricts it to a single multicast island. You can find more details in the Resources .
We now have an overall design for the chat system:
Configure your network to be multicast-enabled. If you have multiple machines on a single hub or switch, they should be able to communicate using multicast without any configuration.
Choose a multicast group and a time-to-live that lets all the desired users connect to your chat session, but prevents messages from travelling too far. For testing purposes, any multicast group in the 239.x.x.x range will do, as will a time-to-live of 1.
Join the multicast group so that you receive messages destined for it. Start a thread that listens for these messages and display them in a text area.
Open a text field for the user to enter messages. To transmit a message to the multicast group, simply drop it on the network bound to the multicast address.
Data communications
IP multicast is built on top of the User Datagram Protocol (UDP). This type of network protocol is packet-based; you construct a packet of information (up to 65,508 bytes long) and dispatch the packet (a datagram ) into the network, bound for a particular destination (identified by an IP address and a port). The network will then try to deliver the packet to the remote address. Upon successful delivery, the recipient will receive the exact payload that you initially dispatched. However, the network sometimes loses the datagrams, sometimes duplicates them, and sometimes misorders them (that is, packets may arrive in a different order than the one in which they were sent). Neither the sender nor the recipient will receive notification of any such network errors. Rather, it is up to the application to identify and surmount such problems. This is one of the complexities of datagram-ba
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Multicast the chatwaves - JavaWorld October 1999
View Tutorial: Multicast the chatwaves - JavaWorld October 1999
Related
Tutorials:
 3D graphics programming in
Java, Part 3: OpenGL
3D graphics programming in
Java, Part 3: OpenGL
|
Jini-like
discovery for RMI
Jini-like
discovery for RMI
|
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
|
Listen to heartbeats using
JMS
Listen to heartbeats using
JMS
|
Jini's relevance emerges, Part
1
Jini's relevance emerges, Part
1
|
Jini's relevance emerges, Part
2
Jini's relevance emerges, Part
2
|
J2SE 1.4
breathes new life into the CORBA community, Part
1
J2SE 1.4
breathes new life into the CORBA community, Part
1
|
Should you go
with JMS?
Should you go
with JMS?
|
Effort on the
edge, Part 1
Effort on the
edge, Part 1
|
Create client-side user interfaces in HTML, Part
2
Create client-side user interfaces in HTML, Part
2
|
To my
mind, of few interest
To my
mind, of few interest
|
Clustering and Load Balancing in Tomcat 5, Part 2
Clustering and Load Balancing in Tomcat 5, Part 2
|
FindBugs - A Bug Pattern Detector for Java
FindBugs - A Bug Pattern Detector for Java
This is the web page for FindBugs, a program which looks for bugs in Java code. It is free software, distributed under the terms of the Lesser GNU Public License.
|
J2ME Technology Turns 5!
In 2004 the Java 2 Platform, Micro Edition (J2ME) celebrated its fifth anniversary. This article presents where J2ME is today.
|
Biological Databases Links
Biological Databases Links
Biological Databases
Biological Databases are like any other databases. Biological Database contains the sequence data of DNA, RNA etc.. These database are organized for optimal retrieval and analysis.
Here are the
|
istory of Bioinformatics
istory of Bioinformatics
History of Bioinformatics
The Modern bioinformatics is can be classified into two broad categories, Bi ological Science and computational Science . Here is the data of hi storical events for both biology and computer
|
Web Hosting Guide. What is Web Hosting Plan?
Web Hosting Guide. What is Web Hosting Plan?
What is Web Hosting Plan?
Web hosting plan is the different plans provided by Hosting Companies for hosting your web site. Web hosting plans include the storage limit, bandwidth, access to server
|
|
|
|
