CSE 489/589 Programming Project # 1, Version 0.8
Fall 2009

Worth 100 points. There might be slight changes to this file in the next 7 days as inevitably bugs and typos are reported. The final version will be version 1.0. (Look, google only releases their betas and you use their softwares daily. Moreover, if you're a software developer, you'll notice that users don't really know precisely what their software requirements are.)

Updates from version 0.7 to version 0.8

Due on Monday Oct 11 at 1:00am [i.e. Sunday night!]. Absolute deadline!

The deadline is hard. There will not be any extension. Any submission after 1am of Oct 11 will not be graded (i.e. you'll get 0 points for this assignment in that case). There's more than a month to do this. No excuse, please.

1. Purpose and basic requirements

By implementing the program specified in this assignment, you will familiarize yourselves with the Unix network programming API (specifically, the Berkeley socket API). The assignment is to be done in groups of size at most 2. You are responsible for finding your partner (if you need one), for finishing off the assignment in case your partner drops the class or backs out from completing the assignment for whatever reason. Please carefully read the sample codes I've given, and build your program on top of the examples. Doing so is not absolutely required, but it will likely save you a lot of time.

The program is to be written in C under a Unix platform such as Linux, SunOS, Solaris, or FreeBSD, or even Mac OS X. Under Windows, it is possible to develop your program with cygwin but you must make sure that:

For portability, please use the Makefile I provided as a template, so that we can compile your program under these two platforms (with a simple change).

The program to be written is called pingpong (or your favorite name), whose features are described below. Note that there is only one program to be written. Many students in the past tried to write a 'client' and a 'server', for unknown reasons.

2. The command line arguments

pingpong takes as arguments a TCP port and a UDP port on which it will listen to incoming TCP connection requests and incoming UDP packets, respectively:
pingpong <tcp-port> <udp-port>

pingpong must handle improper inputs graciously, i.e. some kind of error report and usage information should be printed if the user does not type the correct input parameters, or if the ports cannot be bound, etc. I will post my implementation of pingpong within a week so that you know what to expect. In fact, your implementation of pingpong should inter-operate with mine if you implement the following specification correctly.

3. The commands

pingpong operates somewhat like a Unix shell. It keeps taking user's commands, at the same time watches incoming connection requests and data messages and packets. When appropriate pingpong prints out diagnostic information to stdout and then goes back to the "prompt mode" to accept user's inputs.

We will call each incarnation (process) of pingpong a peer. Below is a description of all commands pingpong is supposed to handle, along with the description of associated actions:

4. Miscellaneous requirements

5. PING message and PONG packet formats

All numeric values have to be in big-endian format. (Test your program with at least a peer running Linux and at least a peer running SunOS, you will see. To know which OS/platform a machine is on, try uname -a.)

PING message format

bytes field content
0-1 type set to PING = 0x00. (you might think that this is redundant, but what if we amend our protocol to include messages other than ping messages? This sort of "place holder" design is very common in practice!). This is in big-endian
2-11 message ID a globally unique identifier for the message. You probably should use the IP, ports, some counter, and random values to construct this ID. Different messages sent by the same or different peers should have different IDs with extremely high probability.
12-15 IP the source's IP address, in big-endian
16-17 TCP port the source's listening TCP port, in big-endian
18-19 UDP port the source's UDP port, in big-endian
20-23 Process ID the source's PID, in big-endian
24-27 Payload length Length of the data that follows.
28- Payload This is the <string> that the user typed, including the '\0' character at the end. Thus, the payload length is the string length plus one!

PONG message format

bytes field content
0-1 type set to PONG = 0x01. This is in big-endian.
2-5 IP the sender's IP address, in big-endian
6-7 TCP port the sender's listening TCP port, in big-endian
8-9 UDP port the sender's UDP port, in big-endian
10-13 Process ID the sender's PID, in big-endian
14- Payload This is the <string> from the ping message that this pong packet replies to, including the '\0' character at the end.