BD350 Assignment Two

BD350 Assignment 4 – Peer to Peer Hangman and Servers Due: Friday, May 9, 2003

Assignment 4 will extend, along several dimensions, the hangman client we created in Assignment 3. These dimensions are:

1. telepointing using UDP. You will need a separate socket object for data that doesn’t require a reliable connection and thus has lower overhead and is faster. I have used port 22220 with success. I also suggest throttling the mouse move messages, i.e. send every 5^th mouse event when telepointing.

2. “pushing” background “jpg” or “gif” graphic files from one peer to another.

1. dealing with network streams – when reading from a stream, the application needs to know how much data to read. For example (in Windows!), when sending data, if the buffer fills enough to trigger multiple TCP PDU sends, then the receiver will have multiple data_arrival events. However, this is non-deterministic. The application, cannot assume that ALL the data will arrive in a single data_arrival event (Java sockets can be set up to buffer this properly). I suggest “pre-pending” the length of the data onto the stream and then peeling that data off with every data_arrival event. Furthermore, you now know that your graphic file length is limited to 32k (the string size limit divided by two – MS appends a null byte for every string character due to its preparation for Unicode). All data should probably be sent using pure byte arrays, but this CAN be done with just string segments.

3. loading background “jpg” or “gif” graphic files from your linux server. Here is some skeleton java code (not fully functional) for a server. Thus, not only will a peer application be able to open a file from a hard drive (and share it as above), but now the application can connect to a server to retrieve a file (and then share it with all connected peers).

4. encrypting data streams – using the RSA algorithm/code provided, encrypt (and decrypt upon reception) all TCP data. You will need to generate your own keys.

My informal description of how this should work would be that when the connection is made successfully, whatever is typed into the chat box on one computer is displayed on the other. Show the username of the person who typed in the text. Chat messages are kept in a buffer for archival reading. Then, if I open a graphic image (from either the local hard drive, or a server IP), it is displayed on my computer and the other one. For the telepointer, it now moves dynamically on all connected computers, i.e. the remote pointers move like the local one.

Extra credit is available in several ways:

1. Implement “negotiated interrupts”, i.e. depending on the desires of the user, either (dis)allow “pushing” of graphics/music. However, set this up as the desires are changed – don’t just refuse the data! (15 points)

2. Serve (both peer-to-peer and from the linux server) music files and play them. (20 points)

3. Serve the graphics/music from the linux machine using MySQL, i.e. store the data in tables and serve it from there. This could also be satisfied by storing game scores or chat transcripts INTO MySQL and then retrieving them when that particular user pair is playing again (keep track of how the hangman games have gone between two pairs of players). (25 points)

A couple of you have requested grading specifications. Here are a few of my thoughts:

1. If it doesn’t compile, grade = 0

2. If it crashes during testing, grade = poor

3. If a graphic cannot be opened from a server and displayed, grade = grade -25

4. If a large graphic cannot be transmitted between clients correctly, grade = grade - 10

5. If a pointer cannot be displayed dynamically and quickly on the other computer, grade = grade -25

6. If the data stream is not encrypted, grade = grade - 30

7. If code is of poor quality, grade = grade -20

Helpful Links

http://www.sockets.com/

http://support.microsoft.com/support/kb/articles/Q163/9/99.asp

http://www.vbip.com/winsock-api/default.asp