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:

• Your submission compiles and runs under both Linux and Solaris/SunOS. We will test your submission on both Linux and Solaris/SunOS machines.
• Except for C++ (which is still not at all recommended), no other language is allowed. I have good pedagogical reasons for this requirement.

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 <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

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:

• info: print the peer's (canonical) IP address, host name, TCP (listening) port, UDP port, and process ID. The output of the info command looks like this:

IP address  | hostname              | udp port | tcp port | PID
------------------------------------------------------------------
192.168.0.3 | funny.cse.buffalo.edu | 4892     | 43444    | 513105

• connect <ip-address> <tcp-port>: try to establish a TCP connection to <ip-address> at port <tcp-port>. For example

connect 192.168.0.3 99999

both sides of the connection then report if the connection has indeed been established or not (i.e. been denied, or IP/port does not exist). The error messages have to be informative on what happened

• show: show all existing TCP connections in the following format:

  cID | IP          | hostname            | local port | remote port
  ------------------------------------------------------------------
    1 | 192.168.0.1 | abc.cse.buffalo.edu | 1234       | 1235
    2 | 192.168.0.2 | def.cse.buffalo.edu | 1453       | 98234
    3 | 192.168.0.3 | ghi.cse.buffalo.edu | 1233       | 09823
    4 | 192.168.0.4 | xyz.cse.buffalo.edu | 1235       | 0823
  

• send <string>: send a ping message containing the <string> to all TCP connections. Here, <string> is the entire text (including blank spaces) that follows the command send (discounting the white spaces right after send). For example, if the user types

  send    Oh! This assignment is a piece of cake.
  

  then <string> is the string "Oh! This assignment is a piece of cake.". The precise format of the ping message will be described later. Briefly, the ping message will contain the ping message's 10-byte ID, the sender's IP, listening TCP port, and UDP port, along with the <string>. Upon receiving a ping message from a neighbor, a peer first checks if it had seen the message before by comparing the message ID against the IDs it has stored in a "routing table". Each routing table is a FIFO queue having at most RTS entries in it. RTS is a constant set to 3, but as a good programming practice we define a constant and use its name throughout the program instead of its value.

  If the peer had seen the ping message before, it will simply ignore the message.

  Otherwise, the peer inserts the message ID into the routing table and forward the ping message as is (i.e. the message content unchanged) to all neighbors except for the neighbor where the message came from. Furthermore, the peer will also send a UDP pong packet back to the source peer of the ping message (the IP address and UDP port of the source are contained in the ping message), informing the source that it has received the ping message. The format of the UDP pong packet, to be specified, basically consists of the peer's IP, the message's string, TCP listening port, UDP port, and the process ID. Finally, the peer also prints the content of the ping message it just received (for the first time). For instance,

  PING received:     Oh! This assignment is a piece of cake.
  From connection #: 2
  source's IP:       192.168.1.104
  source's TCP port: 12345
  source's UDP port: 54321
  source's PID:      55555
  

  The source reports the content of any pong packet it receives to the screen, in the same format as above, replacing PING by PONG, without the connection #. For example, 
  

  PONG received:     Oh! This assignment is a piece of cake.
  sender's IP:       192.168.1.110
  sender's TCP port: 12345
  sender's UDP port: 54321
  sender's PID:      55555

• disconnect <conn-id>: disconnect the TCP connection whose id is <conn-id>.
• quit: quit the current process
• any user's inputs other than the above must be reported as "unknown command"

4. Miscellaneous requirements

• Each peer must be able to handle up to MAX_NO_CONNS TCP connections at the same time. This constant should be set to 3 by default. When the maximum is reached, pingpong will either display an error message (if the extra connection request comes from the command line), or deny the connection establishment request (if the extra request comes from another peer). By "denying a request" I mean simply accept() and then close() the socket right away, which makes your life simpler. Feel free to find other ways to do this, like designing a simple 3-way handshake protocol for pingpong.
• Note that under normal circumstances (i.e. MAX_NO_CONNS is not reached) every TCP connection has to be kept alive until either one end quits or closes the connection.
• When one side of a TCP connection quits or disconnects, the other side must report that the connection has been closed. Here's a sample output:

  connection number 5 was closed by peer

  The side which received the disconnect command from the user reports something like:

  connection number 3 is closed

• Your program MUST use select()for I/O multiplexing of TCP sockets, UDP socket, and stdin.
• Overall, your program must handle errors graciously: print out diagnostic messages that make sense. This is a good habit to develop as you write more and more complicated program.

5. PING message and PONG packet formats

PING message format

PONG message format