Program #3 Notes, rev 3

Last Modified: Mar 7, 2007

Read carefully... this is a modification of our first set of notes (original notes) for Program #3. If you're part of the CLUMP for Program #3, then read on.

Rev 3 changes/additions are highlighted in green.

Requirements

I handed most of this out on Thursday, Feb 22.

Work alone on this one. We’ll work on the design as a group (clump) though.
Implement the CLUMP chat protocol (see below).
P2P, no server/client… the number of direct connections (neighbors) that you will accept should be an input to your program (see below).
Use UDP… yes? I think TCP would actually be tougher to implement in this case… I think. Let’s not worry about packet loss… you can throw in your checksum from Program #2, but I doubt UDP will mess up in the confines of our 2^nd floor lab.
Your program should take the following inputs (without recompiling)
- IP address
- UDP port #
- Max # neighbors to which you will directly connect
- Others?

You must be halfway done by next Thursday… I will accept clean, commented code only
Hey, add a clever extra feature… something fancy in your message or a nice report (graph of the current chat connections) or something similarly creative.
We’ll meet as a group (Sat or Sun before finals) and test it out.
I’ll offer 2 extra points for a “nice” gui
Bulls, Cavs tonight… I’m thinking take the Bulls and the points. [nice prediction, eh?]

CLUMP Protocol

Some terminology:

A clump is a group of 469 guys chatting in a P2P fashion; it's also the name of their protocol
A ClumpApp is an application class/program that implements the CLUMP chat protocol
A peep is anyone joined (connected) to the CLUMP
A peep ID is the unique name of a peep
A neighbor is a peep to whom you are directly connected

Commands must follow the following format:

name -option1 value1 -option2 value2 ... -body body text

So, commands have three parts:

A name,
A list of option-value pairs, and
An optional body of text

The body text is the only data in a command that can contain spaces. I have provided an abstract class to get you going on creating and parsing commands. Command.java is on the k: drive and also here: Command.java

We have thus far agreed on four CLUMP commands:

JOIN -peep <peep-id> -ip <ip-address> -port <udp-port>
- Purpose: issue a request to join the clump and become a peep
- Your <peep-id> has to be unique to the clump; no spaces in your peep ID
- Note that "localhost" or 127.0.0.1 won't work here as an IP, you'll have to get your actual IP so that it can be sent to other machines.
ACCEPT -to <peep-id> -from <peep-id>
- Purpose: a response to a JOIN request, accepting the new peep join the "from" peep as his neighbor.
- The peeps are not yet neighbors... this doesn't happen until a NEIGHBORS acknowledgement is finally sent and broadcast clump-wide.
NEIGHBORS -peep <peep-id> -newpeep <peep-id>
- Purpose: formally introduce a new peep to the clump, along with his connecting neighbor.
- The peeps are now neighbors. Also, you can now send messages to the new peep.
SEND -from <peep-id> -to <peep-id> -body <msg-body>
- Purpose: send the text <msg> from one peep to another.
- If -to is "all", then the command is broadcast to everyone
NEIGHBOR_REQUEST -to <peep-id> -from <peep-id>
- Purpose: ask a peep to list his neighbors for you
- If -to is "all", then the command is broadcast to everyone
NEIGHBOR_REPLY -to <peep-id> -from <peep-id> -body <msg-body>
- Purpose: list all your neighbors in response to a neighbor request

Also, remember, if you receive a command you don't recognize, then pass it on to your neighbors. This will allow parts of the clump (sub-clumps?) to send each other specialized messages that you don't need to deal with, but must pass on through the clump.

The six commands above are gospel.

I am not requiring that your program handle clump exits. If you want to do this, then here is the protocol for an exit and reconstitution of the clump:

EXIT -from <peep-id>
- Purpose: indicate that a peep is leaving the clump.
- This peep should be removed from your peeps list.
REJOIN -ip <ip-address> -port <port-num> -peep <peep-id>
- Purpose: indicate that a peep needs to re-join the clump at a different location (specified in the command) because of an impending exit.
- This command is sent by the exiting peep to all his neighbors, save one. That neighbor will be used to re-connect the clump as the exiting peep shuts down.

A note on processing commands... here's a typical scenario: you receive a command from a neighbor and then you want to pass the command on to all your other neighbors. This ability implies that you know which neighbor sent you the command. This information will be available in the DatagramPacket that you receive. You can find the IP and port source for a DatagramPacket using the methods getAddress() and getPort(). Check it out at the Sun API page: java.sun.com/j2se/1.5.0/docs/api/

Implementation Ideas

We touched on the following classes:

ClumpApp - keep your app code in a separate class, so that you can throw it in a thread. You may want to make this class itself Runnable.
Peep - Each ClumpApp will keep a list of it's neighboring peeps. Should keep a separate list of all peeps? That might make someone exiting a little easier.
Command - Congeal your command creation, packing (into byte[]), unpacking (from byte[]), and options handling in this class.

With our commands setup as solely Strings, you can use the getBytes() method in the String class to convert a String to a byte[]. Also, String has a constructor that accepts a byte[], for you to conveniently translate back as well. We shouldn't have to use any ByteBuffer objects in this assignment as we did in Program #2.

In your ClumpApp, you'll probably want to keep a list of your direct neighbors and also a list of all known peeps. Don't forget your friend ArrayList at times like these.

On Tuesday March 6, I distributed detailed class descriptions from my implementation. Here they are: design_notes.pdf

extra good luck... yow, bill