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 1^st, 2006

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

Introduction

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.

Implementation

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.

Scenario	Description
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

• Provide a complete design and a C implementation for the project.
• Provide your own detailed design since the project specifications constitute a general outline of the required functionality.
• Make any other assumptions you see necessary, as long it does not contradict with the project specifications.
• Up to 2 students can work on the project as a team.

What, When, and How to submit?

• Please submit to the Curator system at http://courses.cs.vt.edu/curator/CourseLinks.html. Follow the link that has our course name and number. Please do not submit binaries or object files. Your source code should be accompanied by a make file and a README file explaining how to generate relevant binaries, and any other necessary information to run your programs. Submission deadline: by Midnight on Monday May 1^st, 2006. No late submissions will be accepted and no deadline extensions will be granted. Every group will be allowed 3 submissions with the last submission being graded.
• What 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

• Schedule a project demo on Tuesday and Wednesday May 2^nd and 3^rd. Sign-up sheets will be provided during class time or a time can be setup by personally contacting the instructor during his office hours. Please do not email your project demo slot time in order to resolve conflicts on the spot. Demo slots are available on a FCFS basis.
• Bring a hard-copy of your project report to the project demo.

How the project will be graded?

The project grade will be based on the following

• A correct and efficient design (25%)
• A correct and efficient implementation tested against a number of test cases (40%)
• A well-written project report (20%)
• Your ability to answer questions during the project demo (15%)

For extra credit

• Provide a suitable graphical user interface.
• Can you design and implement the project without the session directory functionality? Hint. Enable local gateways to discover other local gateways and query them about their active sessions.
• Provide more than one gateway per subnet.
• The session directory can maintain a searchable log of connections and queries
• The gateway can maintain a list of participants for which he is providing bi-directional relaying of chat messages.
• Other ideas?