Virginia Tech

Department of Computer Science

CS4254 Computer Network Architecture and Programming

Spring 2006


Project Outline (Total 100 pts)

Due by Midnight on Monday May 1st, 2006

Project demos on Tuesday and Wednesday May 2nd and 3rd, 2006



This project aims to design and implement a chat session setup service where chat participants can be located in different subnets. Within a subnet, participants in the same chat session will rely on multicast technology to deliver their messages. Multicast connectivity may not be available between the subnets in question. Gateways (for simplicity, one per subnet) will be deployed to provide a relaying service to participants in other subnets. A central session directory is available for participants to lookup which chat sessions they would like to join. Figure 1 illustrates 4 such subnets with different session components.



Figure 1: 4 subnets with different system components. P: Participant, G: Gateway.



A participant can connect through TCP to its local gateway, or to any other gateway at a specific known port. The following usage scenarios can be identified.




Setup a chat session

(from participant to local gateway)

        The participant will send to the local gateway the userís wish to create a new chat session. The user will provide a description and a lifetime for the chat session. We shall denote this subnet as the initiator subnet for that chat session, i.e., any participants not belonging to that subnet, and whishing to receive messages from that chat session, might require bi-directional relaying from the initiator gateway for that chat session.

        The local gateway will assign a multicast address and port to that session

        The local gateway will register with the session directory the chat sessionís information for other participants to lookup (the session directory will check for duplicates)

        Upon successful registration with the session directory, the local gateway sends back the group information to the chat participant

        The participant starts to type messages into the chat session and receives other participants responses (more later on how other participants discover the session)

leave a chat session

(from participant to remote gateway)

        Any participant can leave a session by typing a special keyword (e.g., DONE)

        If that participant is receiving its messages through multicast, it simply leaves the group

        If that participant is receiving its messages through relaying from the initiator gateway, such gateway is informed to stop its relaying service to that participant.

List current chat sessions

(from participant to local gateway)

        The participant sends to the local gateway a list command

        The local gateway contacts the session directory and retrieves a list of active sessions (The list will provide the multicast group information and which initiator gateway to contact to obtain relaying service if no multicast connectivity could be established with the initiator subnet)

        If the session directory could not be contacted, then the local gateway will provide local chat sessions available in the current subnet

        The user selects the desired session and joins the chat session either through multicast or by requiring bi-directional relaying service from the source gateway


Other Design Issues

        Multicast connectivity will need to be tested between any participant wishing to join a chat session and the initiator gateway (You can assume that if a group is capable of receiving multicast from the initiator gateway, then it can receive multicast from the group).

        Multicast address and port for a chat session need to be generated by the initiator gateway. Come up with your own generation technique, but attempt to make the resulting multicast group information as unique as possible.

        A participant will connect through TCP to the initiator gateway to setup the bi-directional relaying service. Figure 2 depicts an example scenario for a bi-directional relaying service.

        The participant will feature a command-line interface, where interactive input is provided from the user, e.g., setup a new chat session. After a participant leaves a chat session. The command-line interface is available to enable setting up new chat sessions or listing currently active sessions.




Figure 2: An example scenario of bi-directional relaying by initiator gateway.

Your task and group information

What, When, and How to submit?

ō      5-10 page project report including your assumptions and design. The report should include the test cases you tested your source code against. In addition, sample snapshots of your run-time output should be provided.

ō      Source code of all your programs

ō      Make file

ō      README

How the project will be graded?

The project grade will be based on the following


For extra credit