| NetProg 2002 HW6 |
| Project Description | Terminology | Functionality | Deliverables | Grading | Submission | Hints | FAQ |
This project must support IPv6! You need to develop a C or C++ chat system (both client and server) that can support up to 10 users (clients) at once. Your system should be client/server, meaning that all chat messages should go through the central server. Your system should be based on a single server.
Your server should be an IPv6 server. Solaris will automatically create IPv4-mapped addresses for incoming clients, so your server does not need to do anything special to support IPv4 clients.
Your client should be capable of using either IPv4 or IPv6,
depending on the server address specified on the command line. If you
use getaddrinfo you don't need to do anything special to
support both IPv4 and IPv6!
Part of your job is to define an application protocol and decide on what kind of transport protocol to use (TCP vs. UDP). Your application protocol will need to be documented and included in your submission.
Some terms are defined here just in case you get confused with later descriptions of functionality (just trying to avoid problems...)
User A human (or a bot) that communicates with the system through a client program. Each user has a nickname that identifies the user to other users. You decide what constitutes a nickname.
User Interface The text interface supported by the client, this is how the user interacts with the system. It is possible that the user interface for this system is minimal, you might even have the user interface be your protocol... It should be possible to store a sequence of UI commands in a text file and feed them to your client program through standard input, so your user interface should be nothing fancy.
Application Protocol The definition of the communication that takes place between the client and server. Note that this can be very different than the communication between the user and the client (but it doesn't have to be).
Message By message, I mean the text that is sent from one user to another (or to all users). You must support text messages. You decide whether text messages are just a single line or multi-line.
Your system must support the functions below.
The system must allow users to identify themselves to the system in some way that prevents the possibility of having two users on the system at the same time using the same nickname.
The system must provide a way for users to send a message to one other user. Only the indicated destination user should receive the message. The user should find out if the destination of the message is not currently on the system.
The system must support some way for a user to send a message to all other users currently on the system.
It must be possible for any user to get a list of the other users on the system. This information includes the user nicknames and the IP address associated with each user. The list shown to the user must support IPv6 addresses and IPv4 addresses (an IPv4 mapped address should appear as an IPv4 address). Note that the user doesn't really care about the IP addresses (they can use nicknames to refer to other users), this is just so we can see that your system can support both IPv4 and v6 clients.
Your client must support a help command so that we can figure out how to use your program. When the client initially starts up it should generate the help information automatically.
You should submit all the files necessary to build and run your client(s) and server. Your submission must also include a file named README that includes the following:
Your Name
A description of your application protocol. This should be detailed enough so that a competent programmer could create a client or server that would work with your programs.
Instructions on how to build and run your programs.
A list of files and a 1-line description of the contents of each file.
References to any borrowed code (the source code must also include this information).
A description of any known problems. If you think you know how to solve the problem(s) and simply didn't have time to do so - let us know how!
Anything else you think might be useful to us, such as what you learned, what you had trouble with, if the project was too hard or too easy, etc.
We won't test your system with anything other than your programs, but we will look for places in your code that could lead to problems if communication does not take place according to your protocol. As always, your server should not create zombies or have memory leaks...
The points for your protocol design are based on your description and the implementation. In general you are not expected to design the fastest, most flexible, most efficient protocol - but don't create a protocol that has silly requirements either. For example, it would be silly to develop a protocol for this application that uses fixed-size 32K bytes messages, as individual chat messages are probably going to be much smaller. It would also be a good idea to design a protocol that could easily be extended if we wanted the system to support more functionality (more users, more message types, etc.).
Points will be awarded as follows (partial credit is available for each item):
| Protocol Design | 25% |
|---|---|
| Client and Server support minimum functions over IPv4 | 30% |
| IPv6 support | 20% |
| Code Style/readability | 25% |
Note that support for IPv6 is worth 20% of the grade, but should be nothing close to 20% of the code! (if you do it right).
Submission of your homework is via email, the general idea is to send an email message with all your files as attachments. There is an automated email submission system that will respond to your submission right away, so you will have a record that we got your files.
All projects must be submitted via email to netprog-submit@cs.rpi.edu. The subject line of the submission message should contain a single number indicating the project number (6 for HW6). You must include your files as attachments, feel free to send a zip-file or a tar file.
Don't send compiled code!
You can expect a return email indicating receipt of your project submission immediately. This receipt will include a list of all the files that were successfully extracted by the submission script - please look over the receipt carefully to make sure your submission worked.
Multiple Submissions: You can resubmit up to 10 times for each project, we will always grade the last submission received unless you tell us otherwise.
Check out getaddrinfo (in the book or in the
lecture notes Advanced Sockets Programming)
Your protocol design will determine how much code you need to write
If you use a simple text-based protocol over TCP you can test
your server using telnet
Don't go crazy with the protocol description. A concise, accurate description is best. It should a technical document, not a novel...
It was a dark and stormy night when I started thinking about my application protocol. As the storm flashed in the sky, my mind wandered to thoughts of Brittney and our on-again/off-again romance. Memories of the good times, like the time she mentioned that our friend Travis 'T.C.' Cook was urinating outside the club (she said "TCP?", I laughed for hours). Memories of the bad times, like when she told me she was considering taking an alternate route... Seems like it was only yesterday...
Anyway, my protocol is text-based. Brittney, on the other hand,
is a multimedia gal - she sings, dances, the whole nine
yards. Speaking of yards, I was watching the storm, and during one
flash I saw that I'd left my laptop in the middle of yard. Funny
thing, but the rain didn't hurt it at all. I almost wish it did
get hurt, as then I'd have something to think about besides
Brittney this protocol design...
Have ideas for a fancy chat system (and the time to implement it)? Stop by and chat with Dave about it!