CSCI 1730                    Programming Project 5A                  Summer 2009

                                 UDP Client


This program is due by midnight on ### Sunday, July 12. ###

The goal of part A of Project 5 is to introduce you to socket programming
by implementing a UDP client.  Your client process will send a message to
a UDP server, recieve replies, and report its activity to the screen before
terminating.  In part B you will implement a UDP server, but for part A you
will be able to test your UDP client by sending messages to the instructor's
UDP servers on odin and atlas.  Those are running on ports 16006 and 2001,
respectively.

Your executable file should be named UDPClient.  It should run from the
command line with three arguments, which we'll call "host," "port_no,"
and "message", in that order.  

The general idea is that there is a UDP server on a host machine which will
recieve messagess sent to it by sendto( ) on port "port_no."  If a UDPClient
command matches the "host" IP and port number "port_no" of the UDP server then
it will receive the client's message and reply, perhaps in several messages.
The UDP client should recieve those messages and echo them to the screen, 
preceded by an explanation such as "messages recieved:".  For example, 

{atlas} UDPClient 128.192.251.5 16006 Message_from_mylogin_on_atlas

if successful would result in something like the following on the screen:

Messages Received:

Hey, got your message.  It was:
Message from mylogin on atlas

Note that your message cannot contain spaces, but the UDP server replaces
underline characters with spaces in its reply.  The UDP server will terminate
its messages with '$', so your client should look for that termination 
character in the messages it receives.  Your UDP client should exit normally
after it receives a '$' in a message from the host and has reported the host's
messages up to (but not including) the first '$'. 
 
Because your message is entered as a command line argument, avoid including
characters such as '!', '?', or '$' in your messages while testing your
UDPClient executable file.

Your project submission should include an implementation file
UDPClient.c, a Makefile and a READ_ME file.  You may include other files
for your implementation, but in any case your Makefile should compile
UDPClient.c and any auxiliary files to UDPClient using gcc upon the
single command "make".

Some things to note:

  *The names of the files submitted and of the executable files generated
   by the Makefile must be followed exactly, so that the teaching assistant
   and the instructor can test your project without editing your code.

  *Your code should perform correctly for servers on different machines.
   Your code should do this from "atlas", "odin", or any of the Linux
   workstations in the 307 lab.
   
  *The first argument for UDPClient should be numerical, for instance 
   128.192.251.5 to connect to a UDP server running on "odin", 128.192.251.4
   for atlas, and the range  128.192.251.[15-34] for Linux workstations in
   the 307 lab.
   
  *As long as you give due credit to the authors, in your READ_ME file and as
   comments in each relevent source code file, it is okay to modify or build
   on code supplied on their web site by Michael J. Donahoo and Kenneth L.
   Calvert (first link under "Sockets and UNIX IPC references" on the
   course "resources" sub-page.)
   
  *On some systems, including "atlas", the gcc compiler needs special
   instructions to search for the libraries which support sockets.  A 
   typical compile command on "atlas" would be 
	gcc UDPClient.c ErrorExit.o -o UDPClient -lsocket -lnsl
   
  *Your programs must be written in C.
  
  *Your programs should be robust and include appropriate error checks.

  *Your project should compile on "odin", or on "albany" or one of the
   other Linux workstations in the 307 lab, using gcc for GCC 4.1.2.
   It should also compile on "atlas" using gcc for GCC 3.3.2.
   Projects which compile properly will be scored out of 100
   (if on time) based on (1) correctness of operation, (2) quality of design,
   (3) coding style and documentation of the source code, and (4) correctness
   and usefulness of the READ_ME file and the Makefile.