Assignment 5: Global Chatting
Out on:
March 3, 2008
Due by:
March 24, 2008, 11:00 am (before lecture)
Collaboration:
Pairs
Grading:
Packaging 10%, Style 10%, Performance 10%, Design 10%, Functionality 60%
Overview
The fifth assignment picks up where the fourth assignment left off, you're going to refactor your chat clients and servers to allow remote connections as well, of course using sockets. In other words, now you'll be going after the instant messaging market for real! Since you are working in pairs again, it's important that you coordinate your schedules and stay in touch during the course of the assignment! Working together in lab or at a laptop in a cafe somewhere is highly encouraged. After the assignment is over, each of you will be asked to evaluate the contribution your partner and yourself made to the assignment.
Scenario
Aside from the change to sockets, nothing really changes about the scenario. The server process that coordinates the chat between all users "connected" to it listens for new clients on some predefined port. If there's a connection, the server tries to negotiate it and eventually either lets the new client in or not. In terms of capabilities of the chat system, you're still bound by the same minimum: Join or leave a chat (with others being notified that a client joined or left) and exchange messages in public. Of course there are many more possible commands, for example a command to get a list of all participants in the chat, a command to "whisper" to another user without others seeing the message, a command to "kick" other users (only for administrators), etc. etc. Those are optional and not required, but both servers and clients should be able to "gracefully" ignore commands that they don't understand and do so without leaking information.
Complications
The major complication for this assignment is once again that all clients and servers that you produce should interoperate without problems. You may have to adjust the protocol hashed out for the previous assignment somewhat to take care of the new "global" dimension of the chat, but hopefully that won't be too bad; just start early this time. :-) A minor complication will be that you will work with a new partner, which means you'll have to decide whose code you're going to use as a starting point for this assignment. See problem 0.
Problem 0: Code Review (20%)
Your first task to perform a code review to see what you can learn from each other's code. Note that you can learn from good as well as bad code, the important thing is to see what others do and compare it with what you did. You should follow the procedure briefly described in class: Exchange the code; read it by yourself first, making notes as you go; then meet and discuss your findings and questions; then decide whose code to start from for the rest of the assignment; then write up your findings, including why you chose one implementation over the other.
In your README file, collect both good and
bad aspects about each implementation you reviewed. The
criteria are obviously vague, but you will no doubt have
to say things about the code, right? Check functionality,
check style, check commenting, see what splint
says, etc.
Once your findings are complete, explain which version
you are going to work from and why.
I strongly recommend being done with the code review by Friday at the latest! You'll need time to actually work on the rest of the assignment!
Problem 1: Chat Server (40%)
We'll grade the server you produce independent from the client (see below). For the server we'll pay close attention to stability and quality of error checking and all those things. You may want to do lots of quality assurance for this one. :-)
Problem 2: Chat Client (40%)
We'll grade the client you produce independent from the server (see above). For the client we'll pay close attention to user interface design and organization. You may want to do lots of usability testing for this one. :-)
Hints
- If you think it's helpful, you can use threads or processes for your client or your server. If you don't think it's helpful, you don't have to use either.
- It's probably a very good idea to implement some sane kind of debugging output, especially for the server; the easiest way is probably to write to standard error and redirect that into a file when you start the server; remember to append to the log, otherwise you'll probably miss important information regarding why your server crashed on a certain input from a certain client.
- Related to the last point: It may be a good idea to identify each team's code somehow, for example by agreeing on a nickname for each team. That way you can check the log and tell the right time what it sent to crash your server.
- It's possible to encapsulate the protocol inside a module. The module would export a bunch of functions to do certain things and put together properly structured buffers that can be sent through the pipe to the recipient. If you want to go that route, you can freely exchange the relevant code on the mailing list. Just make sure you only define the protocol, not half the server, that would be sharing too much code.
- A command history makes the client more usable. A nice curses TUI makes the client more usable. A lot of other things make the client more usable. :-)
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs211-assign-5-login1-login2.tar.gz
with login? replaced by your Unix login names
on ugradx.cs.jhu.edu.
The tarball should contain no derived files whatsoever
(i.e. no executable files),
but allow building all derived files.
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading.
We expect that your Makefile handles "the usual" targets
like clean and test aside from all
(which is the main way we will build your program).
Include other "common" files such as INSTALL describing
how to install your tool, CREDITS to pay your respects
to the people whose code you're reusing, and LICENSE
to describe copyright and distribution terms if you feel like it.
You can look at any number of "famous" open source projects to see
what kind of structure is appropriate;
gif2png
is a relatively small example, but you don't need everything in
there.
Aside from your code, what you really need is a README
and a Makefile that works. :-)
Grading
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to C programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to the amount of resources
your program needs to produce the required results; this can
include space, time, and other metrics.
Design refers to proper modularization and the
proper choice of algorithms and data structures; often this can
be judged by asking "How hard would it be to add feature X?"
and "How hard is it to replace algorithm X with algorithm Y?".
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file; if the specification is too general
and you had to add certain restrictions, defend those in your
README file as well.
If your programs cannot be built on ugradx.cs.jhu.edu
you will get no points whatsoever.
If your programs cannot be built without warnings using
gcc -ansi -pedantic -Wall -Wextra -std=c99 -O
we will take off 10% (except if you document a very good reason).
If your programs cannot be built using make we will
take off 10%.
If your programs fail miserably even once,
i.e. terminate with an exception of any kind or dump core,
we will take off 10%.
Finally, make sure to include your name and email address in
every file you turn in!
