Julian Williams, NPS, December 1998

Overview: Using Multicast Networks, group communication may be established across the Internet via Internet Protocol Multicast addressing at the network layer. However, for members not directly connected to the Multicast Backbone (Mbone), relays must be used to allow unicast clients to receive multicast data. Classes MulticastRelayServer and MulticastRelayClient were defined to permit unicast users to receive multicast data. These classes allow users who are not directly connected to the Mbone to receive multicast PDUs.

Problem: Although the MulticastRelayServer allows multiple MulticastRelayClients to connect, the server has no method to determine if its clients are alive or if they have lost connectivity with the server. Thus the server will continue to transmit multicast packets to non-existent clients.

Solution: The MulticastRelayServer and MulticastRelayClient classes were modified to allow continuous communication from the server to each of its clients and it additionally allows the server to discontinue delivery of multicast packets to clients whom no longer exist. In addition, a finalizer method was added to the MulticastRelayClient class to force the client to delivery a final disconnect message to the server in the event of an unforeseen client failure.

Lessons Learned: This project consumed considerably more time than I initially planned for. I began by trying to modify the server to deliver a "hello" message to each client and then use a delay technique to wait a predetermine amount of time before sending another "hello" message. I soon discovered that this approach was infeasible because the main goal of the program is to listen for multicast data on the Mbone and then transmit that data to each of its subscribed clients. I then attempted to build a separate thread to handle the transmission and receipt of the hello and reply message between server and client. After considerable time and effort, I finally discovered why my first technique failed. I started by having the server send a hello message to each client, verify that each client received the message properly, and then have the client send a reply to the server thus closing the loop. Everything worked fine except the server would never seem to get the reply from its clients. Upon further investigation I realized that the server initially spawns a thread to listen for connect and disconnect requests from clients and thus my newly created "I am here" messages was being received by this listening thread and being ignored. Upon tackling that problem, I then realized that I now needed the ability for the client to distinguish PDU packets from hello packets. I attempted to solve this with a reply procedure which checks each packet received to determine if it is a PDU to be relayed or merely a hello message from the server. Once this was handled, I was able to set up a sufficient delay mechanism to allow the server to request reply messages from its clients once every few minutes and have the clients only respond when queried. The server now has the task of tracking which client has not responded within three consecutive tries and then proceeds to delete the non-existent client from the multicast client roster. This was both a frustrating (initially) and somewhat rewarding exercise when things actually started to work.

Future Work: There is much room for continued work in this area of refining the server and client classes to allow more reliable and more efficient performance. The server should create a log file containing delivery and receipt time stamps to monitor, which clients have connected and which have disconnected normally. Those that are disconnected from the server for protocol non-compliance can be identified and further analyzed. This information could be posted to an Internet web page for general access. Web users could access the page to gain valuable status information on the server, along with its current workload, network performance parameters, and other status data based on the response/reply delivery times. MBone administrative folks could also use this information to perform network analysis and planning.