The Protocols

Now for the fun part. We need to define two protocols for how this is all going to work. In many ways, the protocol I propose here is just a start with many possible enhancements left to be made. As part of this assignment we will be evolving the details. In particular, we may decide that some additional messages are necessary to get this to work as we like. At a minimum, we will most certainly need to further clarify the semantics and behaviors of a correct implementation of our service.

First, what is the interface between your client and the rendezvous server? When the user joins a group, before you indicate the successful join, you must send a UDP query to the rendezvous server and request a list of group members.

Join message from client to rendezvous server:

1. Message Type - 1 byte - value is ASCII character "J" for Join
2. Group Name - Variable length character sequence terminated by ":" - ASCII name of group to join
3. User Name - Variable length character sequence terminated by ":" - ASCII name of user joining the group

Response message from rendezvous server to client:

1. Message Type - 1 byte - value is ASCII character "S" for Success or "F" for failure
2. List of group members and their IP addresses, represented as a sequence of Username:Address: pairs
   1. User Name - Variable length character sequence terminated by ":" - ASCII name of user in group
   2. IP Address - A 32-bit integer in network byte order
      Note that the ":" character appears after the address integer. This was not in the original specification but was in the reference implementaton.
3. The message terminates with "::" to mark the last group member. You should see yourself in this list.

The join message will cause a group to be created if you specify a group that does not exist. In this case you will be listed as the only member of this group.

What about getting the list of current groups? Here is the protocol for that.

List request message from client to rendezvous server:

1. Message Type - 1 byte - value is ASCII character "L" for List

List response message from rendezvous server to client:

1. Message Type - 1 byte - value is ASCII character "G" for Groups.
2. List of Group Names, separated by ":"
   1. Group Name - Variable length character sequence terminated by ":" - ASCII name of group
3. The message terminates with "::" to mark the last group name.

Now what? Once you have a list, you must try to join the group network by connecting to one of these group members. You will connect to them using the same port, 8421. You will simply go through this list of IP addresses, trying to connect to each one. Once you find a successful connection, you don't have to try any more nodes. This node will be your link to the chat group.

For simplicity, we will define just one message type for the peer-to-peer protocol. This message contains the text that some user has typed. The format is as follows:

1. Message Type - 1 byte - value is ASCII character "T" for Text
2. Group Name - Variable length character sequence terminated by ":" - Group name for which this message is intended.
3. User Name - Variable length character sequence terminated by ":" - Original user that sent this message
4. Message ID - A 32-bit integer in network byte order - This is a unique identifier for messages from this user.
5. Message Length - A 32-bit integer in network byte order - The number of bytes of data in the user's message.
6. User Message - The message data - Note that there is no termination character. You must read only the indicated number of bytes or you will run into the next message!

So, what do you do when you receive such a message?

1. First, you check the group name to see if this is the group you are in. If not, drop the message and close this socket. Apparently someone connected to you with outdated group information.
2. If this is your group, you should check the username/messageid values to make sure this is a new message you haven't seen before. If you've already seen this message, do nothing.
3. If this is a new message for your group, you have two jobs. First, display the message for the user by printing it with the username. Next, you must forward this message to any other users that are currently connected to you.

Oh, and one other important point. The rendezvous server will maintain the current list of group members but we did not define a "leave group" message. Instead, the rendezvous server will drop any members of the group it has not heard from in the last 2 minutes. You will need to periodically resend your join message to the server while you are actively participating in the group.

Sample Chat Session

Here is a sample successful chat session, with a simple command line interface, starting and ending with my shell command prompt on tokyo. You should come up with a nicer interface, this is just an example.

tokyo> p2pchat gomez.cc.gatech.edu:8421
P2PChat>list
 GTBasketball
 Sailing
 SocketProgramming
P2PChat>join Sailing Russ
 ...connecting
Sailing>send
Send>Ahoy Mates!
Sailing>
 From: Gilligan> Ahoy Skipper!
 From: Blackbeard> Arrrrgh.
Sailing>leave
 ...closing group
P2PChat>quit
tokyo>

Notes

1. As before, your programs are to be written in standard Java and should run on the GTL Linux systems. You may develop your program anywhere but be sure it works at GTL.

2. I'm using a server in Atlanta as the rendezvous server so you should be able to access it from home. However, note that you will have to deal with NAT if you have one because other clients will need to connect to you!

3. A portion of your grade will come from demonstrating your programs in the lab at GTL. We will do this together during class time in our own interoperability test. I encourage you to do some interoperability testing with your classmatest ahead of time.

4. Your client/server will be handling several different sockets. First, to the rendezvous server. When the user issues a join request, you must send a message to the server to get the group list. Second, you will have a connection you open to at least one other peer. (Unless you are the first group member.) And finally, you must be prepared for other peers to contact you! You must have a socket bound to port 8421 where you periodically check for new clients and preapre to receive messages from them.

5. You will need to maintain a list of other peers you are currently connected to via open sockets. You will periodically cycle through this list of sockets to see if there are any new messages for you to process. For new messages, you will forward them to all of the other open sockets except of course for the one on which it arrived.

6. You must test your program and convince me it works! Note that you should be able to test your program against itself. Simply run the same program, connecting to a group as a different user.

Turnin Instructions:

1. You will turn in your well-documented source code and a README file. The README file must contain:
   1. Your Name and email address
   2. Class name, date and assignment title
   3. Names and descriptions of all files submitted
   4. Detailed instructions for compiling and running your client and server programs.
   5. A description of your application design (1/2 to 1 page)
   6. Any known bugs or limitations of your design or program.

   You will be graded on the correctness of the code and its comments, readability and structure. The documentation will account for (25 percent) of your homework grade.

2. By 23:55 on the due date, you must submit your program files online.
   1. Use the UNIX "tar" command to create an archive of your complete set of files, naming your .tar archive file "p1_lastname_firstname.tar": (e.g. tar cvf p1_burdell_george.tar
      
   2. Email the resulting tar file as an attachment to me at rjc@cc.gatech.edu using the subject line CS6250 Program 2.