|
Target platform
The assignment will be marked on cis-lab.ml.unisa.edu.au, make sure your program is able to run on this host.
Specifications
It is very important that you follow the instructions in this document exactly!
The name of the directory you must use in CVS is assign2. Make sure you spell it exactly the same, with the correct case (do not use any upper case letters - Unix is case sensitive!).
Make sure that you test your code on Cis-lab to ensure that it will work for our marking system. Make sure you submit your code early and often.
Your program must be started using the command lines specified later on in this document.
No graphical outputs required. Outputs of both the client and the server are text based.
You must include a text file in plain ASCII called evaluation.txt which contains a written description of what grade you think you deserve, and a justification of why this is so.
Reminder: Please close your client and server once you finish your tests, to free the CPU/memory/port resources for other students. Your process will be killed if you leave them running over 24 hours.
Overview
In this assignment, you will be required to implement client and server programs for a shared white board application. The application requires two components to be implemented, the client and the server. The client allows a user to manually input drawing commands, which is send to the server. The server then takes these messages and sends them to all of the other clients connected to it. The end result is that all clients can see the drawings being entered by the other users, and the server provides the ability to connect them all together.
Program Requirements
You are required to implement a client in Java as a console based application, which is capable of taking inputs from the user and sending them across the network. Messages from the network must be displayed as text on the standard output device. The server must also be implemented in Java, as a simple console based application. You are free to implement your Java code for the client and server in any way that you like, as long as it meets the following guidelines:
It must run on Cis-lab using only standard JDK classes and no other external classes
The server should not have any user interface but may print out text debugging
You must use the network protocol and ports that we have specified in this document
You must use the supplied command lines to start up your client and server
This assignment is broken up into two parts, the client and the server. We will provide a server that implements the protocol specified in this document which you can use to test your client against while you are developing it. The provided server will also be useful to allow you to test your assignment with other students who are testing at the same time. When your client is working, you can then use it to test out the server that you have implemented yourself.
Network Protocol
The protocol that is used in this assignment is based on a simple text format to make it easy to implement and debug and problems. Messages are sent over a TCP connection to guarantee reliability and delivery, and also to provide a simple transmission mechanism similar to writing to a file. Each message is sent as a command followed by the required arguments, using a single space character as a separator and a new line character to end the command. Note that the client can exit by simply closing the connection to the server, and the server must handle this cleanly. There are a set of protocol messages that you will be required to implement.
Client to server messages
LOGIN [username]
The client sends this message to the server when it initially connects. The server will not process any other messages nor allow the client to see any drawing messages until this message has been processed. The username must contain only the letters A-Z, a-z, or the digits 0-9, any other characters such as punctuation or spaces are not allowed. The server must check to ensure that usernames are unique, so that no two clients may connect with the same user name.
DRAW [x1] [y1] [x2] [y2] [colourname]
Server to client messages
WELCOME [any other data may go here]
This message is sent by the server when a new client connects to it. The welcome message may contain a string containing any number of characters including spaces. You may put whatever
welcome message you would like clients to see, and would typically include your name and any other descriptive text. The client must display this text so the user knows what server they have connected to.
LOGIN_OK
This message is sent by the server when it has received the LOGIN command from the client. It indicates that the server is now ready to accept DRAW commands from the client, and will pass on messages from other clients.
DRAWMSG [username] [x1] [y1] [x2] [y2] [colourname]
This message is sent by the server whenever a client sends a DRAW message to it. The server is responsible for working out the username of the client connected to it that generated the DRAW message, and then generating a new message which is sent to all of the clients. Note that this message is sent to all of the clients, including the client that generated it. The coordinates and colours are specified in the same way as the previous DRAW message.
ERROR [reason string]
If the server does not understand a message that the client sent to it, the server should generate an error message so that the client can print this out for debugging. This will be useful as you test your client and server against those written by others. The reason string must be a single line of text and can contain any characters including spaces - it should be descriptive enough so that the remote client programmer knows what their program has done wrong. Some example messages could be:
ERROR Cannot accept DRAW command until after LOGIN request ERROR DRAW command contains a value which is out of bounds ERROR The supplied username is already in use
After generating an ERROR message, the server should close the connection and not try to continue processing because there is an error in the protocol implementation (probably caused by the client, although this is assuming the server does not have any bugs in the code). Note that if the server fails then it may simply close the connection without any response, and the client should then terminate with an error message.
Protocol ordering
When a client connects to the server, messages will be sent back and forth in the following order. Any other order is not supported. Note that the server is not required to store drawing commands internally, so if a client joins the server later than other clients, it will miss out on any lines drawn beforehand. An ERROR message may occur at any time and after this the server automatically closes the connection. The startup sequence is as follows:
Client
Server
Open connection to server hostname:port
Accept connection from the client
WELCOME Welcome to this server
LOGIN JamesBond007
LOGIN_OK
When ClientA generates a DRAW message, it will be sent to the server, which then will send a DRAWMSG to ClientA, ClientB, and ClientC.
ClientA
ClientB/ClientC
Server
DRAW 50 55 100 105 red
DRAWMSG ClientA 50 55 100 105 red
Command Line Arguments
Both the client and server will be controlled via command line arguments on start up. For the client, you will need to specify the Internet host name that the server is running on, the TCP port number to connect to, and the username to use. For the server, you will need to specify the port number to listen for incoming connections on. If other users are on the system you will need to pick a port number that is not currently in use. When we mark your assignment we will make sure that we use a port number which is available for use.
For the client, the command line syntax must be:
java Client [hostname] [port] [username]
For the server, the command line syntax must be:
java Server [port]
Hostname is any acceptable Internet machine name: either a machine name, a fully qualified domain name, or an IP address. The port number is a single integer value, and will be above 1024 since only these are available for user applications. The username must be in a format which is suitable for transmission using the protocol described earlier.
It is expected that you will check all command line arguments to ensure they are valid and generate a suitable error message if they are not correct.
Test Server
You can test your client by connecting to a test server, which is using port 9999. When you are testing your server, please avoid using port 9999.
Program Operation and Marking Procedures
Your client must be started from within a class named Client. Your server must be started from within a class named Server. Both of these should be stored within a directory named assign2 on the CVS repository. The source code will be compiled and run using the following commands:
# Check out and compile cvs checkout os-2010sp2/bondj007 cd os-2010sp2/bondj007/assign2 rm -f *.class javac *.java # To run the server (we will vary the port number to pick one that is free) java Server 10000 # To run the client (this is an example only, the host and port will change) java Client cis-lab.ml.unisa.edu.au 10000 JamesBond007#p#分页标题#e#
Both the client and the server should only use the standard console objects System.in and System.out. You should not use non-standard libraries for your implementation. Everything you
use for your assignment should be in either your *.java source files or in the standard Java libraries on Cis-lab. Even if your code works under Windows you should test it on Cis-lab to ensure that it will work for the markers.
Your evaluation.txt file must include a grade that you think your assignment deserves. You should then justify why you think you deserve this grade and describe what parts of the marking criteria you have or have not met. You will be penalised if you make exaggerated claims in this file. Make sure that your file is plain ASCII text, and is not in a binary file format from Microsoft Word!
Error Checking and Code Style
It is bad programming style not to include comments and useful error messages in your program. If you write a program without comments, after 3 months you will completely forget how the program works and it might as well have been written by someone else!
You should check for every possible error condition that is possible. If an exception can be thrown, you should catch it and print a useful error message explaining what went wrong. We should never see exceptions being thrown when running your assignment; if we see any exceptions you will lose marks.
All possible error conditions should be checked for as strongly as possible. Any invalid command line arguments or invalid protocol messages should be handled appropriately without exceptions or incorrect behaviour being observed. In particular, note that the client should never send draw commands outside of (0,0)-(499,499), and the server should reject all requests which fall outside this range. Since we are writing network applications in this subject, it is important to realise that while you are running your server, any student can connect to it and send any messages they want. Your server and client should not be vulnerable to attacks from rogue clients or servers with any kind of invalid data. As part of testing your assignment, we will send corrupted junk data to your client and server to make sure they behave correctly.
Frequently asked questions
The supplied test server appears to be down, what should I do?
You should send email directly to [email protected] and we will restart the server as soon as possible. Do not send these to the forums or the other email addresses otherwise it might take 24 hours. Unfortunately there are some students who are intentionally crashing the server, causing problems for all the other students.
Do we need to deal with blocking problems in the server?
Yes. Your server must be able to handle a poorly behaving client that does not read in its data. You should be able to start up two clients, pause one of them with Control-Z, and the other one should keep working indefinitely. You need to ensure that you have a thread for each socket which is responsible for sending your outbound data.
Submission Details
Marking Criteria
This assignment is worth 15% for the entire OS subject. This is a large amount of marks and if you fail this assignment it will severely affect your overall grade and you may even fail overall.
The marks for this assignment are out of 100, and are broken down as follows:
Component
Weighting
1
Accurate evaluation of marks in the evaluation.txt file, which is easy to read
5
2
Correct use of the CVS system for submission - the logs should show multiple versions of Java files indicating incremental development and the use of CVS to track changes. Do not submit blank CVS changes because these will be ignored!
5
3
Neatly formatted code with comments explaining the operation of the code.
5
4
Successful compilation with no fatal errors, start up for operation, and no run time errors during simple testing
15
5
Ability for the student’s client to connect to the official OS test server and successfully share data with another connected client
25
6
Ability for the student’s server to be used by an official OS test client and successfully share data with multiple clients
25
7
Ability for the student’s server to handle corrupted or rogue client data by always generating the required behaviour
10
8
Ability for the student’s client to handle corrupted or rogue server data by always generating the required behaviour
10
Total
100
CVS Submission
As with all previously marked work for the OS subject, you will be required to use the CVS repository to submit your assignment. We will not accept submissions via any other mechanisms such as email! Details on how to configure and use the CVS repository are available in practical 0 for the subject. Since you should have used CVS for all of your practical work to date, you should not have any trouble checking in your work to the repository.
Assuming your username on Cis-lab is bondj007, you should have checked out your CVS repository using the following commands:
export CVSROOT=:pserver:[email protected]:/home/cvs cvs login cd ~ cvs checkout os-2010sp2/bondj007
You should then create a directory called os-2010sp2/bondj007/assign2 to store the files for this practical:
mkdir ~/os-2010sp2/bondj007/assign2 cd ~/os-2010sp2/bondj007 cvs add assign2 cvs ci assign2
You should then store all your assignment files within the assign2 directory. Make sure you add and check in each file you have created as soon as possible. You must add all of the .java files to
the repository that are required to compile your assignment - do not submit any other files such as .class or javadoc output which is generated by a program. It is ok to add other files such as testing files and so forth. Note that you need to both add and check in a file, just adding it does not copy it into the repository until it is actually checked in:
cvs add filename.java cvs ci filename.java
You are free to make as many changes as you like to any of your files - in fact we encourage you to take advantage of the features CVS has to offer you. For example, if you have a version of your code that compiles or performs some part of the assignment, check it in. That way, if you make a mistake later or if you lose all the files on your computer you can go back to an older working version. Before cleaning up your code for final submission, you should check your code in to save a copy of it for reference. If it turns out you introduced a bug into your code while adding comments but fully working code can be seen as an older version in CVS, we may be able to take this into consideration for you. Marks for this assignment have been allocated to proper use of CVS with history, multiple versions fixing bugs and adding new features, etc, so you should try to use CVS features as much as possible and then you will get these marks for free.
The CVS repository is accessible from anywhere on the Internet, so you do not have to just use it from Cis-lab. If you want to work from home you can just as easily check code in as on Cis-lab, but you will have to configure an appropriate CVS client on your machine. If you do not know how to do this, please use Cis-lab which has detailed instructions on how to use CVS. Note that while you may develop your assignment on any machine, you must verify that it runs correctly on Cis-lab, since this is the machine we will test your work on. You should check in all your code from home, then login to Cis-lab and check out a copy of the same code and verify that it works correctly. Not testing your code on Cis-lab will not be accepted as an excuse for your assignment not working. Note that Windows is not case sensitive and it will allow incorrectly cased file names - you should ensure that the case is correct by checking the code out on Cis-lab and compiling it, copying it to a corrected file name if necessary.
It is very important that you verify all of your code is checked into CVS. You should firstly make sure that you have checked in all directories and files in your repository directory. If you see any files marked with a ? then you have not checked them in.
cd ~/os-2010sp2/bondj007 cvs update -d -P
The next thing to do is verify that all of your CVS code actually works correctly. In practical 0 on CVS, you should have checked out a second copy of the repository to verify what is actually in the repository. If you have not done this, the following is the command which will checkout a copy of your repository to os-2010sp2-verify in your home directory.
cd ~ rm -r os-2010sp2-verify <-- be very careful here cvs checkout -d os-2010sp2-verify os-2010sp2/bondj007
Once you have performed this checkout, you should update the sources using CVS and then check that your code successfully compiles and runs on Cis-lab. Once this step is complete then you can be sure your assignment has been submitted correctly.
cd ~/os-2010sp2-verify/ cvs update -d -P
Note the use of the arguments -d -P on cvs update, these tell CVS that it should update any new directories that have appeared as well. CVS will normally only read in directories that have been checked out already, so using -d -P ensures you get a complete up to date copy of the entire repository from where you run the command.#p#分页标题#e#
If you have spelled your directory or any files incorrectly, you cannot simply just rename them because the CVS repository needs to be notified properly. CVS requires you to create and add new directories, and copy your files over manually. For example, if you need to move files from the directory incorrect2 to assign2, then do the following (be careful here!):
cd ~/os-2010sp2/bondj007 mkdir assign2 cp incorrect2/*.java assign2 cd incorrect2 cvs remove -f *.java cvs ci cd ../assign2 cvs add *.java cvs ci *.java cd .. cvs update -d -P
Assessment conditions
The course information guide contains a number of conditions for the subject, including policies on extensions and marking. Generally, unless described in the course information booklet, extensions will not be granted! Extensions will definitely not be given for preventable problems such as losing source code due to viruses or hardware failure - you should be using the CVS repository to store all of your code and so loss of your code should not be possible. Last minute problems caused by forgotten passwords, CVS errors that are caused by you, and incorrect submission will also not be acceptable. If you cannot use CVS to submit your code then it is not acceptable to submit it to us via email, you should make sure you test and use CVS well in advance of the submission date if you are unfamiliar with it. Naturally if you have a good reason we may be lenient here, but trivial excuses will not be accepted.
Late Submissions
If you submit your assignment after the specified deadline without a pre-arranged extension, a penalty of 20% of the total mark per day (including Saturday and Sunday) will be incurred. For example if you are 2 days late and you are awarded 20/25 your actual mark will be 15/25.
Plagiarism
Deliberate academic misconduct such as plagiarism is subject to penalties. You are advised to become familiar with the University’s policy available at http://www.unisa.edu.au/adminfo/policies/manual/misconduct.htm and also the slides which were presented during the first week of lectures.
Note that we have a number of electronic systems in place to quickly and easily check for plagiarism amongst students. All of the assignments are compared using special tools designed to look for similarities between Java programs. The plagiarism checking programs do not just compare the actual Java code, but instead perform comparisons on the code after it has been compiled. Performing cosmetic changes such as reformatting code, renaming variables, or
reordering code may fool a human under casual inspection but will still be detected by the plagiarism checker as being similar. By using the CVS repository regularly, it can be used as proof of your incremental development of your own source code - if someone copies your code then it will be obvious who the original author is.
Any assignments found to be in violation of the university’s rules on academic misconduct will automatically receive zero. Furthermore, you may also fail the subject and/or receive an official note in your academic transcript.
The best way to avoid being penalised for plagiarism is to not cheat on your assignment. Do not share your code with anyone, do not let any one else do your assignment for you, and do not leave your computer unattended or share your password with anyone. If you are working with friends it is ok to discuss the assignment and possible ways of solving it, but you should not share your code. Sharing code with others is still considered academic misconduct. The golden rule for working on your assignments is never show another student the material you intend on handing up.
|
 |
|||
| 网站地图 |
