Description
Create and test a Simple Document (SD) server and client, using ONE of the following:
- .NET System.Net. with C# on Windows.
- Win32 winsock2 with C++ on Windows (extra credit)
- UNIX sockets with C++ on UNIX (extra credit)
The service will be used and enhanced along with other assignments this term.
Note: This assignment assumes a working PRS is available from Assignment 1. Use the instructor’s implementation if necessary.
SD Server
The SD server application should meet the following requirements:
The SD server will listen on a TCP port that will be used to receive connections from SD clients.
The server port number must be requested from a PRS, like we built in Assignment 1. Use the service name “SD Server” when requesting a port from the PRS. The SD Server port must be kept alive while being used, and closed when done.
The server must take the following command line arguments:
-prs <PRS IP address>:<PRS port>
When the server starts up, create an empty session table. The session table should be a dictionary (or map), where the key is an arbitrary “session id”, unsigned long, and the value is a “session”. The session consists of any information the server needs to remember about the client and a table of “session values”. Session values are basically another dictionary of arbitrary key/value pairs, both key and value are strings.
When a client connection is made, a thread should be created to process commands on that connection. While that new client thread is running, the server should listen for additional connections.
Extra Credit Option: Create an initial thread pool, of a limited size, for client connections. When a client connects, allocate one of the threads to that client. If a thread is not available, do not accept the connection until a thread is available. When the client is done with it’s connection, return the thread to the pool.
Each client connection should be associated with it’s own session. The first time a client connects, a unique session is allocated for that client and sent to it. The client will send the session id back to the server each subsequent connection. The client will end it’s session explicitly to deallocate that session id. Session ids should not be re-used.
Extra Credit Option: Establish a timeout period for sessions. If a client does not resume it’s session soon enough, then the session is closed and further attempts to use it will be rejected.
The server can receive and process the following commands once a client is connected:
open\n
resume\n<session id>\n
close\n<session id>\n
get\n<document name>\n
post\n<document name>\n<length>\n
<document contents>
Note commands and their parameters are always separated by a line-feed ‘\n’ character.
The open command begins a new session. The server responds with the following:
accepted\n<session id>\n
The resume command attaches a client to an existing session, if it exists. The server responds with the following if the session exists:
accepted\n<session id>\n
… Or responds with the following if the session does not exist (or has timed out):
rejected\n<reason string>\n
The close command ends an existing session. The server responds with the following:
closed\n<session id>\n
The get command requests a specified document from the server. The server responds with the following if the document exists:
success\n<document name>\n<length>\n
<document contents>
… Or responds with the following if the document does not exist:
error\n<error string>\n
The post command sends a specified document to the server. The server responds with the following if the document is accepted:
success\n
… Or responds with the following if the document is not accepted:
error\n<error string>\n
The server sends the following when it receives a get or post command without a valid session open:
error\n<error string>\n
Documents are unique by name, always text and the length is measured in bytes.
Sample conversation:
<client connects for first time>
client: open\n
server: accepted\n1\n
client: post\nfoo\n4\n
<client sends foo’s 4 bytes of content>
server: success\n
<client disconnects>
<client reconnects>
client: resume\n1\n
server: accepted\n1\n
client: get\nfoo\n
server: success\nfoo\n4\n
<server sends foo’s 4 bytes of content>
client: close\n1\n
server: closed\n1\n
<client disconnects>
In this first implementation of the SD server, documents are stored in and retrieved from the client’s session data, where the document name is the key and the document contents are the value.
Client
The client application should meet the following requirements:
The client must take the following command line arguments:
-prs <PRS IP address>:<PRS port>
-s <SD server IP address>
-o | -r <session id> | -c <session id>
[-get <document> | -post <document>]
The client connects to the PRS at the given address:port, looks up the port for the “SD Server” then connects to the server at the given server IP address and discovered port number.
For session use…
-o open a new session
-r <session id> resume an existing session
-c <session id> close an existing session
Print the request and response for each session command.
For document requests…
-get <document> get the requested document
-post <document> post the document, contents read from stdin
When the client receives a document, print the document name, length and contents to stdout.
Example invocation of client to implement sample conversation above:
SDClient -prs … -s … -o -post foo < foo.txt
Opening new session
Accepted session id 1
Posting 4 bytes of foo
Success
SDClient -prs … -s … -r 1 -get foo
Resuming session id 1
Accepted session id 1
Getting foo
Success, received 4 bytes of foo
… foo’ish contents …
SDClient -prs … -s … -c 1
Closing session id 1
Closed session id 1
Submission
Turn in you source code in a zip file called CST415_Assign3_your_name.zip (e.g. “CST415_Assign3_Pete_Myers.zip”. The zip must include source for both client and server. The instructor should be able to compile, run and verify your program. This means you need to include your Solution/Project or Makefile as appropriate.
Handout Code
The “CST415 – Assignment 3 Handout” zip file includes the following classes. Some classes and methods are already implemented. Each method that requires implementation contains a TODO comment.