Description

This document describes CSE 590YA's modified version of the HTCPCP protocol we reviewed last week -- the CoffeeLink Network Protocol (CLNP), version 1.1.3. It was created from components of three groups' Homework 2 submissions.

Your assignment is for your group to implement either a client or a server (or both, if you're feeling especially ambitious) using the standard Berkeley UNIX socket library or the Windows WINSOCK library. We will present a tutorial on these libraries in class on July 11, but if you already know what you're doing, feel free to start working.

Recommended Readings

You might find the following texts helpful in your implementation:

1. Comer & Stevens - Internetworking with TCP/IP, Vol III: Client-server programming and applications, Prentice-Hall 1997
2. Cheswik & Bellovin - Firewalls and Internet Security: Repelling the Wily Hacker, Addison-Wesley 1994

In addition, here are:

• the lecture slides regarding the standard UNIX network functions: PS / PDF
• the socket demonstration in Lisp that Ira walked us through: sockets.cl / examples.cl

Guidelines

The assignment is due as finished source and compiled code on Wednesday, July 18 (beginning of class). More details will follow regarding how we will grade your submissions, but here are some important things for now:

• your client should be able to interface with any group's server (and vice versa) over a network that we will set up.
• the more people there are in your group, the more bells and whistles we expect to see. For instance, any group with five or more people should implement a fancy UI with lots of error-catching (for the client) or a well-designed runtime information display (for the server). People implementing on their own need only support the stipulated protocol specifications.

Questions & Clarifications

Please send mail to Dan and Ira if you have questions.

Here's some Q&A generated so far:

1. Using JAVA network support
   Q: You mentioned we should use the Berkeley UNIX socket library or the Windows WINSOCK library. Are we still able to use Java and the associated libraries? Some of the socket details are hidden in the layer (such as the client-side hostname conversion to a sockaddr_in structure or the client-side bind).

   A: This is OK, especially if it allows more time to build a nice user interface for the client, or a nice display from the server when it is running.
   

2. Multi-threaded vs. single-threaded servers
   Q: Java has no equivalent to the "select" system call. Instead, multiple connections are generally implemented using a thread per active connection. Is this OK or would you like to see us multiplexing multiple concurrent client connections? I guess a more general question is "if implementing the server, should we assume a single-client model or should we support multiple simultaneous connections (like a real server would)?"

   A: A single-threaded server is sufficient for this assignment, but if you want to do a multi-threaded one, that is ok too. In real life, there are plenty of single-threaded servers, and multi-threading is not necessarily the "real" way to do it. In particular, most DICOM implementations are single-threaded.
   

3. Expectations for the client
   Q: Some people have e-mailed with questions about my expectations for the client. The most common one I've had is whether the client has to do anything other than pass the user's commands to the server.

   A: The answer to this is YES! If you're implementing as part of a team, you need a "useful" user interface, etc. But even if you're implementing by yourself, the following client behavior is not sufficient:

   [Client] Please input network command.
   [User] BREW NOW C 3 7
   [Client] Server reports: 200 OK Starting to brew
   [Client] Please input network command.
   .
   .
   .
   

   Your client should *not* assume that the CoffeePot User knows anything about the Network Protocol! Instead, you need some sort of abstraction like this (although the example below is certainly not complete enough):

   [Client] What would you like to do next?
   (a) check status of CoffeePot
   (b) brew more coffee
   (c) dispense currently brewed coffee
   (d) add additions to my coffee
   (e) reset the coffee pot
   [User] b
   [Client] When would you like to start the brew? (use HH:MM format or 'now' for immediate brew)
   [User] now
   [Client] Would you like caffeinated (C) or decaffeinated (D) coffee?
   [User] C
   .
   .
   .
   [Client] Thank you for your input. I am now sending your selections to the CoffeePot.
   .
   .
   .
   [Client] The CoffeePot reports that the brewing process started successfully.
   .
   .
   .
   

   So, your client is responsible both for guiding the user through the input process AND for parsing the server's responses and making them somewhat intelligible to the user. THIS DOESN'T HAVE TO BE FANCY, but it should be complete.

   The difference for TEAMS who are implementing a client is that we want to see a GUI, or at least a very well done ASCII front-end (perhaps using ncurses or something like that) ...

4. Carriage return [CR] vs. line feed [LF]
   Q: The term 'new line' in the spec. is kind of vague. Does it mean a CR + LF, or does it just mean one of them? In my code I am checking for the existence of a '\n' to verify the validity of command. I have been using Windows HyperTerminal to test my server. By default, upon pressing ENTER, it only sends a CR with no LF. I had to change its default setting to send a line feed as well.

   A: This is an important point. The strings passed over the network should be terminated with LINE FEED. This is "\n" in C, C++, Perl, etc. If you are using Windows products to test your code, you should be aware that they probably send CR by default.