Project1

advertisement
CNT 5106C
Project 1
25 May 2012
Summary:
You will develop two programs, one a client and the other a server, that use UDP to
communicate. You will also develop and document the protocols used by the two processes.
The server will accept messages that allow it to insert, delete, and search for records containing a
IP address, and port number. Later projects will build on this project to expand the records and
to expand server functionality.
Languages:
You will use Java, C++, C#, or C to implement the client and the server.
Records:
Records have the following structure.
IP address: dotted decimal notation in ASCII characters
Port number: decimal unsigned integer in range 1024...65535
Server:
The server must be able to be started on a host and open a port number specified either in a
configuration file or on the command line.
The server must at least accept four types of messages:
1. Insert record
2. Delete record
3. Retrieve record
4. Die
Insert message must include all the fields of the record to insert. If a record with the same IP
address and port number is already stored, then the server must return an error message.
Delete message must include at least the IP address, and optionally port field. If the fields
supplied in the delete message match a record, then the record is deleted. Otherwise, an error
message is returned.
Retrieve message must specify the IP address field. The IP address is a dotted decimal address,
with zero or more of the decimals replaced by “*”, which matches any value in that part of the IP
address. The server must find all records that match IP address supplied (with wildcards), if any,
and return the number of matching records and all matching records to the client.
If a die message is received, the server shall terminate cleanly. The server persists until the die
message is received.
In all cases, the server shall send at least one reply message indicating the result of the request
(successful or error). In the case of a retrieve message, the server may send multiple messages to
the client. It is up to the protocol you design to specify how the client and the server interact if
multiple records are retrieved.
The server must be able to receive and process messages from multiple clients as long as it is
alive, one request at a time.
Client:
The client program must accept commands from the user via the standard input and print results
to the standard output.
The client must accept the following user commands:
1. Server <IP address> <port number>
2. Insert <IP address> <port number>
3. Delete <IP address> [<port number>]
4. Find <wild_IP>
5. Kill
6. Quit
The Server command sends no messages, but sets local variables used by the client to contact
the server. All subsequent commands that involve sending messages use the values set by this
command, until another Server command or Kill command is issued. The client checks for
validity of IP address and port number, and either prints an error message or echoes the valid IP
address and port number. If no server IP address and port have been specified, or if the server
has been terminated, then any commands that would otherwise result in sending a message must
instead print an error message indicating that the server parameters have not been initialized.
Insert causes the client to check validity of the remaining fields and either print an error message
or send an insert message to the server with the fields provided. In the latter case, the results
from the server are printed.
Delete causes the client to check validity of the remaining fields and either print an error
message or send a delete message to the server with the fields provided. In the latter case, the
results from the server are printed.
Find causes the client to check validity of the remaining field and either print an error message
or send a retrieve message to the server with the field provided. In the latter case, the results
from the server are printed, including all matching records formatted reasonably (one record per
line).
Kill causes the client to send a kill message to the current server and print the server’s result
message (sent before it dies).
Quit causes the client to quit, without sending any further messages.
Bonus:
The server may store its records in a file which may be specified on the command line or in a
configuration file so that the information persists when the server is killed.
The client may implement a Test command that sends a test message to the server. If the server
does not respond within 5 seconds, the client prints a failure message; otherwise the client prints
an indication that the server is responsive to the test message. The test message need not be a
new message, and the client need not print the server’s exact response to it.
Deliverables:
You will submit a tar file containing the following files.
1. Server source code
2. Client source code
3. Makefile, if appropriate
4. Configuration files, if appropriate
5. Documentation of protocol (exact message formats, tests, actions)
6. User documentation of server and of client (how to install, configure, and use)
7. In Java, C++, or C. Your program must be able to be compiled by the compilers and run
on the following environment: thunder.cise.ufl.edu
Download