Program #3 Notes

Last Modified: Fri Feb 23, 2007

If you're part of the CLUMP for Program #3, then  read on.

Requirements

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

  1. Work alone on this one. We’ll work on the design as a group (clump) though.
  2. Implement the CLUMP chat protocol (see below).
  3. P2P, no server/client… the number of direct connections (neighbors) that you will accept should be an input to your program (see below).
  4. 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 2nd floor lab.
  5. Your program should take the following inputs (without recompiling)
    • IP address
    • UDP port #
    • Max # neighbors to which you will directly connect
    • Others?
  1. You must be halfway done by next Thursday… I will accept clean, commented code only
  2. 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.
  3. We’ll meet as a group (Sat or Sun before finals) and test it out.
  4. I’ll offer 2 extra points for a “nice” gui
  5. 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

There are 3 basic CLUMP commands:

  • JOIN <peep-id> <ip> <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.
  • SEND <from-peep-id> <to-peep-id> <msg>
    • Purpose: send the text <msg> from <from-peep> to <to-peep>
    • If peep-name is "all", then the message is broadcast to everyone
  • EXIT <peep-id>
    • Purpose: indicate that a peep is leaving the clump
    • The peep's neighbor(s) will have to figure out how to keep the P2P chain going.
  • NEIGHBOR_REQUEST <from-peep-id> <to-peep-id>
    • Purpose: request a neighbor list from one peep to another.
  • NEIGHBOR_REPLY <from-peep-id> <to-peep-id> <peep-list>
    • Purpose: reply to a neighbor list request, return a list of your neighboring peeps
    • The <peep-list> is a comma-separated list of peep IDs.
  • ?????
    • If your ClumpApp receives a command that it doesn't know, then ignore it
    • Therefore, sub-clumps can have their own mystery commands all to themselves

I cleaned up some of our terminology. There are still some issues:

  • When I join, how do I know who accepted me as a neighbor? I mean 1) I find out the IP/port of someone in the clump, 2) I send out a JOIN, and then 3) I sit by my UDP port waiting for a reply. What is that reply? Do we need an ACCEPT command issued by the new peep's accepting neighbors? Or maybe the accepting neighbor sends a welcome message to the new peep. Bring an opinion on this to class Tuesday.

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.

Also:

  • If you didn't "get" packing and unpacking into byte[] in Program #2, please see BillBytes or my Segment class for help. You'll have to pack a command into a byte[] to send it using UDP.
  • I notice that ByteBuffer doesn't have a putString() or getString(). You can convert String data to byte[] using the getBytes() method on a String, then use put( byte[]) from ByteBuffer. We need to work on this... we'll probably have to stuff the size of the String into the ByteBuffer as well to read it back out again. Maybe I'll add this to BillBytes, we'll see.

Like I said, come to class Tuesday with an opinion. We'll talk these issues through after the exam.

thanks... yow, bill