Sentence Server

SE424: Distributed Systems
Semester 1 5777
Assignment 1
Due: 14 Dec 2016
Sentence Server
In this assignment you will create a simple client/server tool which implements a simple communication
protocol. The server in this case will enable clients to store sentences, delete them, and search for them.
1
The Communication Protocol
The client and server will speak a protocol built on the following message types:
ADD sentence The line begins with ADD (capitalization is not important) followed by one space. The rest
of the line is a sentence which may contain many spaces. Trailing spaces at the end of the sentence are
ignored. The line ends with a new line character.
REMOVE sentence The line begins with REMOVE (capitalization is not important) followed by one space.
The rest of the line is a sentence which may contain spaces. Trailing spaces at the end of the sentence
are ignored. The line ends with a new line character
SEARCH sentence The line begins with SEARCH (capitalization is not important) followed by one space.
The rest of the line is a sentence which may contain spaces. Trailing spaces at the end of the sentence
are ignored. The line ends with a new line character
YES The line contains just the letter YES, but capitalization and extra trailing spaces are not important.
The line ends with a new line character.
NO The line contains just the letters NO, but capitalization and extra trailing spaces are not important. The
line ends with a new line character.
OK The line contains just the letters OK, but capitalization and extra trailing spaces are not important. The
lines ends with a new line character.
ERROR The line contains just the letters ERROR, but capitalization and extra trailing spaces are not important. The lines ends with a new line character.
CLOSE The line contains just the letters CLOSE, but capitalization and extra trailing spaces are not important. The line ends with a new line character.
The protocol messages above are the ones sent by the client and server programs. The user will not need
to write the commands above or see the responses in the protocol. Instead, the user will interact with a
client interface program as described in the following section.
2
The Client Program
When the client program starts, it first reads from a configuration file which contains the following information: (1) a server IP and (b) a server port. It stores the server IP and server port for later, when the user
requests to connect. This will let the user point the client program to a different server without needing to
recompile the code and without the user needing to enter the server IP and port manually. Assume that
the configuration file will be read only once, when the client program starts up and doesn’t need to be read
again during execution.
1
Note: You choose how to implement the configuration file, but you must document the configuration file
and how it works in the README file for the assignment.
The client program lets the user perform the following operations:
Connect Connect to the server listed in the configuration file. The user can then perform any number of
the sentences operations below during a single session.
Disconnect If the client program is currently connected to the server, it disconnects. The user can later
reconnect to the server without needing to restart the client program.
Quit Close the client program. If the client is currently connected, it must disconnect from the server before
quitting.
Add a sentence If the client program is connected, the user can enter a sentence to add to the server’s
sentence database. If the sentence is already in the server’s database, an error message is shown to
the user (the server returns ERROR if the client tries to add a sentence it already has). Otherwise, a
success message is shown to the user.
In this case the client sends ADD sentence message to the server and receives either an OK or an ERROR
message in return.
If the client isn’t connected to the server, the user can’t perform an add. The client program may
optionally show the user an error message.
Delete a sentence If the client program is connected, the user can enter a sentence to delete from the
server’s sentence database. If the sentence isn’t currently in the server’s sentence database, an error
message is shown to the user (the server returns ERROR if the client tries to delete a sentence it doesn’t
have). Otherwise, a success message is shown to the user.
In this case client sends a REMOVE sentence message to the server and receives either an OK or an
ERROR message in return.
If the client isn’t connected to the server, the user can’t perform a delete. The client program may
optionally show the user an error message.
Search for a sentence If the client program is connected, the user can enter a sentence to search for in the
server’s sentence database. If the sentence is found in the server’s sentence database, a found message
is shown to the user. Otherwise, a not found message is shown to the user.
In this case the client sends a SEARCH sentence message to the server and receives either a YES message
or a No message in return.
If the client isn’t connected to the server, the user can’t perform a search.
The client program shall offer a GUI or a text based interface with the above operations available. The
user must not be required to enter raw protocol commands such as ADD, REMOVE, and SEARCH. Protocol
messages must be sent by client program in response to user requested operations using the GUI or text
based interface.
The choice of the interface and its design is up to you. but must document the user interface and how it
works in the README file for the assignment.
3
The Server Program
The server program offers a multi-threaded interface to a single, shared sentence database. When the server
starts up, it first reads from a configuration file which has the following information:(1) a server port and
(2) a list of sentences. The server loads the information from the file when it starts up and keeps it ready
for later use. Assume that the sentence database will be small enough to fit into a single .NET or Java
Collections data structure such as a string array, an ArrayList, a Dictionary, or a Vector.
2
Note: You may choose how to implement the configuration file, even making more than one server configuration file if it’s convenient, but you must document the configuration file and how it works in the README
file for the assignment.
The server program lets the user perform the following operations:
Start Listening The server automatically shows the user the server computer’s current IP address and
allows the user to modify it before starting to listen. The server program can implement this (a)
graphically by displaying a text box which contains the computer’s IP address and enables editing or
(b) using just the command line by showing the current IP address and allowing the user to enter in
a different one before starting to listen.
Once the user has approved the server IP, the server program starts to listen on the IP address provided
and the server port retrieved from the configuration file. It also prepares the sentence database for
reading and modifying.
Once listening, the server program must handle multiple concurrent conversations with clients. Each
concurrent conversation must be handled by a separate worker thread (ex.BackgroundWorker). Assume
the number and rate of connections will not be large enough to require the use of a thread pool (but
you may use one if you wish).
Stop Listening If the server is currently listening, it must stop doing so. All worker threads must be closed
down as soon as possible. Once the user has told the server to stop listening, it must prevent any more
updates to the sentence database.
The user can choose to start listening again without needing to restart the server program.
Save and Quit If the server is currently listening, it first does the actions listed above in Stop Listening.
It then saves the current state of the sentence database to the configuration file and ends the program.
The server can offer a GUI or a text based interface. The choice of the interface and its design is up to
you. You must document the user interface and how it works in the README file mentioned below.
3.1
Worker Threads: Handling a Client
Each worker thread for the server program must be able to handle a single conversation from a client program.
The worker thread must perform the following actions in response to messages from the client:
ADD sentence The worker threads checks if the value sentence is currently in the sentence database. If
yes, it replies ERROR. Otherwise, it adds sentence to the database and replies OK. Once added to the
database, a sentences will be visible to all current and future client conversations.
REMOVE sentence The worker threads checks if the value sentence is currently in the sentence database. If
not, it replies ERROR. Otherwise, it removes sentence from the database and replies OK. Once removed
from the database, a sentence will no longer be visible to all current and future client conversations.
SEARCH sentence The worker threads checks if the value sentence is currently in the sentence database. If
yes, it replies YES. Otherwise, it replies NO.
CLOSE The worker thread closes the connection. There is no reply.
Other If any other message is received from the client program, the worker thread replies ERROR.
3
Log The worker thread must keep a verbose log of each operation. The log may be printed to the console,
shown in a text box, or stored in a dedicated log file. If you choose to use a log file, its location must be
documented in the README file for the assignment. The log must contain the following fields:
• The IP and port of the client program.
• The complete command or action which occurred or which the client program sent (connect, disconnect,
add, remove, search, close, unknown)
• The reply the worker thread sent back
3.2
Thread Safety
Since there may be more than one worker thread running at once and each one may try to add, remove, or
search the sentence database, you will need to implement a mutual exclusion mechanism to prevent state
problems in the sentence database. Read the .NET or Java documentation to see which classes are thread
safe and learn about the lock and synchronized key words in .NET or Java. There are a few ways to
achieve thread safety, some easier and some more complicated. You may use any one of the ideas below in
your code or you may come up with your own idea:
1. Use lock or synchronized on all critical blocks or methods.
2. Implement a separate sentence database class which uses lock or synchronized
3. Save your sentences to an SQL database. (Note: If you choose this option you must ensure the
database can be submitted with the assignment and accessed on any Windows 7 computer).
Document your thread safety strategy in the README file for the assignment.
4
Additional User Interface Requirements
Both the client and server programs must support the following requirements:
1. Robustness: The server and client programs must perform error handling, not crashing due to unhandled exceptions.
2. Responsiveness: The server and client programs must enable the user to interact with the user interface
when listening or processing. This implies that network communications must not be done on the same
thread as the user interface.
4
5
What to turn in by 14 Dec 2016
You may work in groups of up to two (2) students. Each member of the group must turn in a single ZIP
file via Moodle which contains the following items:
• The full source code for all parts of the system.
• A compiled version of the client program runnable on any Windows 7 computer, along with any required
configuration files.
• A compiled version of the server program runnable on any Windows 7 computer, along with any
required configuration files.
• A file called README.PDF which has the following information:
– A list of the students in the group, including names and ID numbers
– A detailed list of which student worked on what and for approximately how many hours
– Instructions for compiling the source code for both the client and server programs
– Instructions for running the client and server programs
– Documentation of the client configuration file
– Documentation of the server configuration file(s)
– Documentation of how thread safety is ensured
6
Grading
The weights for the grading will be assigned as follows:
• Client program: 30%
• Server program: 50%
• Thread safety: 15%
• Robustness: 5%
The following penalties will be assessed for the errors or omissions below:
• Hard coding file names, IP addresses, or port numbers into the code. (-15) points
• Not handling quit or save and quit correctly. (-15) points
5