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 ...