Killer Game Programming in Java

UDP Multicasting Clients and a Name Server

Figure 30-4 shows the various objects in the multicasting chat application.

Figure 30-4. Multicasting chat system

Each user is represented by a MultiChat object that can send and receive messages from the multicast group. However, this isn't a pure peer-to-peer example since a client must first log in to the NameServer object and receive the address of the group. Upon leaving the group, the client must log out from the server. Each client has a name that is checked by NameServer for uniqueness. If the name is being used by a group member, then NameServer rejects the request to log in.

As a side effect of storing user names, NameServer can process who messages. Instead of a client multicasting a who message to all the other group members and receiving multiple replies, a single who message is directed to the NameServer followed by a single response. This approach significantly reduces the number of messages circulating in the system.

As discussed in the context of the threaded chat server, the main drawback of using NameServer is that it represents a single point of failure. However, NameServer's disappearance only prevents new clients from joining the group. Communication between existing members can continue. The other consequence of NameServer's demise is that who messages will no longer be answered.

NameServer must be able to handle multiple ...