4514 Project 2

You're tired after a long day. Your professors have been brutal with the homework, especially your Computer Networks prof. You need to unwind with your friends, but you also need a good jolt of caffeine so you can pull an all nighter and finish your programming assignments. Where can you do both? Why, the local coffee shop, of course!

This assignment serves as an introduction to client-server programming using the TCP/IP protocols (UDP and TCP). In this assignment, you will write on program, chat, that acts as both a client and a server. Your chat program will implement a simple two-person chat session. Your chat will act as a server when it is waiting for a connection (the analogy: you are just hangin' out in the coffee shop, waiting for someone to come talk to you. It will act as a client when it connects to someone else's chat which is waiting for a connection (the analogy: you spy your best bud sippin' some joe, so you cruise over to see what's up).

A key aspect of client-server programming: How does the client chat find out where the server chatis? That is, what transport-level address (Internet address and port number) should the client connect to?

One solution is to use a name server that dynamically maps service names into their transport-level addresses. We will supply you with a such a server, called the Central Perk (ala Friends), allowing you to register that you are hanging out as a chat server, waiting for chat client to connect to you (the analogy: the Central Perk is a room full of coffee-drinking, hard-working college students who are sick of classes and stuff and just want to shoot the breeze for awhile). Conceptually, the Central Perk is like the white pages in your phone book. A server registers the name and transport address of its service in the phone book, and clients use the phone book to map service names to transport addresses.

Your chat client must allow a user to communicate with the server (via list, add, delete, where commands, see below), hang out and wait for someone to connect (act like a server) and connect with someone else's chat program (act like a client). It must also be robust in the face of lost UDP messages to or from the server. Other than those basic functionalities, you are free to design your client in any way you want, including nicer interfaces for the chat sessions, easier commands to communicate to and from the server, an so on.

A bonus of 10 points will be rewarded to groups that have exceptional clients. Use your imagination! As a sample of a fairly unimaginative client, you can try out our chat at /cs/cs4514/proj2/chat. No warantees, etc on its robustness :-), but it should give you a sample of at least one possible client

You communicate with the Central Perk server via the below header file:

/* perk.h */
/* header file for Central Perk server */
/* version 1.0 */

#define PERK_HOST "wpi.wpi.edu"
#define PERK_PORT 4514
#define MAX_DESC 60		/* maximum description length */
#define MAX_NAME 10		/* maximum name length */
#define MAX_HOST 35		/* maximum host length */

enum type_list {list, where, add, delete, end, error}; 

/* contains the info for a chat room */
struct info {
  char name[MAX_NAME];		/* name of user */
  char description[MAX_DESC];	/* description of user */
  char host[MAX_HOST];		/* host user is on */
  int port;			/* port user is listening called */
  int when;			/* time last added, in sec since 01-01-70 */
};

/* message block understood by server.   Note, not all the fields
 * are used for each message */
struct message {
  enum type_list type;	/* the server command, message type */
  struct info person;
};

You can also copy the Central Perk header file from /cs/cs4514/proj2/perk.h.

The Central Perk server runs on host wpi.wpi.edu at UDP port 4514. You communicate with the server by passing a C structure struct message back and forth. The message contains a type field and an info field. The type field specifies a command to the server or a reply from the server. The info field may contain valid information, depending upon the command or the reply. Here are the specific commands understood by the server:

• list - list who is currently hanging out at Central Perk waiting to chat. The server ignores the info field for the incoming message. The server sends messages back to the client, a separate message for each person in the Central Perk. These messages have "list" in their command field and information on each person in their info fields. After information on the last person is sent, the Central Perk sends a message with "end" in the type field.

• where - give information on where (host, port) the person is. The server looks at the info field for the name of the person, copies in the host and port fields and returns the message.

• add - add the person to the Central Perk. The server checks if the name is unique. If so, it makes a new entry. If not, it checks if the host and port for the additional entry are the same as the host and port for the current entry. If so, the when timestamp is updated. If not, the person is not added. The server does not return anything from this command for success or failure.

• delete - remove the person from the Central Perk. The server checks matches the name, host and port from that in the info field. If there is a match, the person is deleted. If there is no match, no action is taken. The server does not return anything from this command for success or failure.

The following system calls may be helpful: clearerr(3), gethostname(2), listen(2), close(2), getpwent(3), getuid(2), send(2), recv(2), getservbyname(3), gethostbyname(3), gethostbyaddr(3), getsockname(2), bind(2), socket(2), connect(2), accept(2), listen(2) and select(2).

Here are a few suggestions for development:

1. Start early. Debugging client server code is sometimes difficult. Debugging client server code across separate hosts is even more difficult. Building a client to talk with a 3rd-party server is even more difficult, still. This is not to scare you, rather it is to encourage you to start as soon as possible in case you get "stuck."

2. Work on each part separately. You can develop the chat of the client independently of the client part that communicates with the server and takes commands from the user.

3. Start with the sample code. The best way to learn network programming (maybe any kind of programming) is through examples. Take the samples from the course web page (listen.udp, talk.udp, listen.tcp and talk.tcp) and go from there.

4. Start small. Write a procedure that sends a datagram to the Central Perk server, and receives a datagram response from the server. The list command is the easiest one to get going at first. The server has some "canned" people hangin' out in it all the time so you should get some responses. Take a similar strategy for the chat part of the client.

The main information I'd like you to have from the documentation standard is; author, date, project id, language, OS dependencies, description and building information. All this information should appear in a README file that accompanies your program.

Here is a sample of the information you should have:

Author:                         Mark Claypool
Date:                           1/21/00
Project ID:                     Project 2
CS Class:                       CS4514
Programming Language:           C
OS/Hardware dependencies:       None

Problem Description:            This program implements blah, blah, blah

How to build the program:       make