USQStudyDesk: Dashboard > Fac of Hlth, Eng & Sciences > 2016 Semester 2 > CSC8415_2016_2 > General

> Assignment 1 instructions

USQ TIME 11:24 am Sun, 14 Aug 2016

Computer Network Programming

Assignment 1 instructions
CSC8415 Assignment 1

CSC8415 Assignment 1
Network Programming

Introduction
The assignment will be marked out of 100. This assignment is worth 30% of the marks for the course.
The assignment submission will have two parts, program code and a word processed report in PDF format.
The code goes into the Git repository, and the report will be submitted using the USQ Studydesk
assignment submission.

Assignment Topics
Recall that in assignment 0, you learned :The use of the Git repository.
The use of a makele.
C command line arguments.
Using pointers in C
Calling functions in C
Writing functions in C
Reading from and writing to les.
Encapsulation in C.
Conguration
Logging
In Assignment 1, you will build on everything you learned in assignment 0, and use it to perform professional quality network programming complete with error
handling. Specically, you will design and implement a networking client and a networking server, and they will communicate with each other.

Task Overview
1. Test the demonstration networking client that connects and communicates with a server.
2. Add command line arguments processing to the demonstration client so that you specify the address the port number, and the lename on the command line of
the client.
3. Improve the demonstration client by comprehensively implementing the missing error handling.
4. Test demonstration networking server that accepts connections from a client, and communicates with a client.
5. Implement conguration and logging for the server.
6. Improve the demonstration server by comprehensively implementing the missing error handling.
7. Design a protocol for a networking client and networking server to request and transfer les. The protocol should cover the circumstance where the server cannot
deliver the le, because, for example, the le may not exist.
8. Implement and test the designed networking server, complete with conguration and logging, that can accept the le name of a le from your client and deliver
the requested le.
9. Implement the networking client that can request a named le from the server as per your protocol design.

10. Test the client and server.

The following applies to all assignments in this course.

If you are stuck at any stage, which is likely, then seek help in the practicals or on the forums. Hopefully
someone has already had the same problems as yourself, and you can simply read the solution. If not, then
you need to ask.
The student is expected to produce quality code. The code should be properly formatted and properly
commented.
Code needs to be checked into the Git repository as it is being developed. The marker will view the current
contents and the history of the student's Git repository.
Your marker will inspect, compile and run your code on the Linux operating system as provided for this
course. The marker will go to the directory associated with the question and inspect the code. He or she will
type the command "make" in order to compile the program.
Hopefully, the program should compile without errors. Compiler warnings are usually an indication of
something not being done correctly. If you cannot ascertain the cause of a compiler error or warning, then
seek help in the tutorials or the course forums.
The issue of plagiarism is taken seriously. USQ policies on plagiarism may be found here.

Script
The linux command line interface, called "bash", has a command "script" that will collect all the command line input and output. You will need to use this in order to
capture your testing for your report. Type

$manscript

in order to see the documentation for script. Here is a demonstration of script. Type the word "script". Then do things. Then when you are nished, type "exit", e.g.:
$scripttemp1
Scriptstarted,fileistemp1
$echohithere
hithere
$ls
BinCoursesmd5sum.txtPicturesSvnVbox
BioconDesktopMiscpoco1.7.3TempVideos
BioconOldDocumentsMntPublictemp1
bolwin10.7zDownloadsMusicSharedTemplates
$exit
Scriptdone,fileistemp1

Now you can view the output in a text editor, copy/paste into your report, or simply use the command "more" to see what you have captured, e.g.


$moretemp1
ScriptstartedonThu28Jul201611:30:55AEST
$echohithere
hithere
$ls
BinCoursesmd5sum.txtPicturesSvnVbox
BioconDesktopMiscpoco1.7.3TempVideos
BioconOldDocumentsMntPublictemp1
bolwin10.7zDownloadsMusicSharedTemplates
$exit
ScriptdoneonThu28Jul201611:31:07AEST
$

Network Framework Documentation

The documentation for network framework exists in the network framework header les, and you will need
to read these carefully in order to complete the work in this assignment.
For example, if you want to know just what a given netCli_???() routine does, and what the return value is,
you will nd the documentation for the routine immediately before the prototype for that routine in the le
"netCli.h" in the place where you installed it.

Part 1
The instructions posted on the home page show how to build the networking framework and how to install
it on your computer. Do this rst.
Then make a subdirectory "Part1" in the "Assignment1" directory within your Git repository. You will use
and improve the sample code from the provided networking framework. Copy all of the sample code,
including the makele and test.ini into "Part1".
Type "make" in order to build the sample code.

a) [2 marks] Test the demonstration networking client.

Running the networking client should cause it to request a le from a well known web site, and print out the response, which should indicate that the requested le
does not exist. You need to capture this test in your report.

b) [4 marks] Add command line processing to the networking client.

The address, port number, and le requested have been hard coded into the demonstration client, and you
need to change this so that they are specied on the command line.

c) [5 marks] Add error handling to the networking client.

The demonstration client has no error handling. If it fails, then it fails mysteriously. Error handling is required in order to turn this into professional code.
The error handling you are expected to implement in the client should display an error on "stderr" and then
quit. There needs to be error handling for:The command line processing. There could be the wrong number of arguments, or the arguments could be invalid.
The opening of a "FILE*" stream, using "fdopen".
Reading or writing to the TCP stream.
Some of the netCli_???() calls return an error indicator.

You need to read the documentation and modify your code to check for an error return. When you detect
an error return from a framework routine, you need to obtain the details of the error using an error
message method, which in this case is netCli_getErrMsg().

d) [3 marks] Test the demonstration networking server.

Running the networking server should cause it to listen for connections and read one line from each connection before closing the connection. You can test it from a
second command line window using a telnet client. For example, if we do the following in our second window:
$telnet127.0.0.19991
HelloWorld

Then our command line window running the server should show:
$./netSrvDemo
Connectionfrom127.0.0.1
Gotline:"HelloWorld"

You must show your server testing in your report.

e) [10 marks] Add conguration and logging to the networking server.

You need to add logging to the server. The logging needs to be initialised very early, if not rst so that
errors can be logged.
The server demonstration code has the address of the server interface and the port number hard coded.
You need add conguration to the server, and you need to get these things from the conguration.
Make sure that new connections are logged at the NOTICE level.
It is acceptable for the location of the conguration le and the location of the log le to be hard coded into
the server.

f) [6 marks] Add error handling to the networking server.

The demonstration server has no error handling. If it fails, then it fails mysteriously. Error handling is
required in order to turn this into professional code.
As explained in Assignment 0, is is inappropriate for a server to print error messages to standard error.
Servers generally run in daemon mode where the streams that are normally connected to a command line
console, i.e. standard input, standard output and standard error, have been disconnected.
The error handling that you expected to implement in the server, therefore, will involve sending a log
message at the ERROR level and then exiting the program. The only time it is acceptable to write the error
to stderr, is if the initialisation of the logging system itself fails.
Just as you did for the networking client, you need to look at the documentation for each function call made
in the server. Wherever you detect an error, you need to get the details of the error and log it before exiting
the server. There may well be some conditions where you can log an exception at the WARNING level and
keep the server going.

Part 2

You will design and implement a client and server where the client requests a le from the server, and the
server sends the le to the client, if it can.

g) [30 marks] The Design

You need to design how the client and server talk to each other.
Importantly, your report needs to thoroughly document the protocol that the client and the server use to
talk to each other. You will express your design by means of English language and by means of diagrams,
including a state transition diagram.
Some aspects to consider when you are designing, are:How does the client and the server conrm the protocol that they are going to use?
What sequence of characters does the client use to request the le? Will this take the form of words on a line?
How does the server know that the request is complete?
How does the server indicate that it has the le and will send it?
How does the server indicate that it will not send the le (possibly because that le does not exist) ?
In case the server will not send the le, how does it tell the client the reason why it will not send the le?
In case the server will send the le, how does the client identify the beginning of the le?
In case the server will send the le, how does the client know when the end of the le has been reached?
The marker will evaluate whether your design addresses each of the above concerns. You need to describe
your design completely so that the answers to all of the above questions are made clear by reading your
design.
It is recommended that you appreciate HTTP's GET command before you consider your design. You may
well decide on a cut down version of HTTP's GET, but you may use any design that you come up with. You
will nd a denition of HTTP in Wikipedia, and also plenty at W3C, but I recommend James Marshal's HTTP
Made Really Easy.
It makes sense to choose a design that you can easily implement. CscNetLib has some routines that will
help you with the implementation. Take a look at the short tutorials on how to parse lines and transfer les.
There is also a demonstration "lePropertiesDemo.c" in the Samples directory of CscNetLib that shows how
to tell if a le exists and what its size is.
The design, complete with state transition diagram is to go into your report.

h) [20 marks] Implement the server.

The work that you have done so far is a good base for your implementation because the error handling has
been implemented and the logging and conguration has already been set up. Do the following to create
the starting point for your server:1. Remove the object and executables from "Part1" by typing "make clean".
2. Make a copy of the directory "Part1" and call it "Part2".
3. Rename "netSrvDemo.c" to be "getFileSrv.c". Rename "netCliDemo.c" to "getFileCli.c". and change the makele to reect the name changes.
4. Compile and test your new client and server to ensure that you are OK so far.
5. Begin to modify the server in order to implement your design.
The base directory where the server nds les should be specied in the conguration.
Your server should be of professional quality, complete with error handling, logging and conguration. It
may be appropriate to cut and paste text from your design into comments for the code.
Instructions on how to parse the line using routines provided in the library are given in the home page.

Take special care of your handling of binary les. Your call to fdopen(), if you use fdopen(), should use the
string "r+b". Binary les are not line based, and cannot be written a line at a time.
It may well be better to implement the server rst, as it may be tested using a telnet client before your
purpose built client has been built.

i) [15 marks] Implement the client.

The client may simply write the le that it obtains to standard output. Redirecting standard output does not
redirect the standard error, so that error messages may still go to the screen. Invocation of the client may
well be similar to the following example:
$getFileCli127.0.0.19991myfile.txt>myfile.txt
FileobtainedOK

or possibly like this

$getFileCli127.0.0.19991myfile.txt>myfile.txt
Error:Serversaysfiledoesnotexist.

Modify the client in order to implement your design. Your client should be of professional quality, complete
with error handling.

j) [5 marks] Test the client and the server.

Your report should include the testing of the client and server:Demonstrate what happens when the le exists.
Demonstrate what happens when the le does not exist.
Do zero length les get transferred properly?
Do les with a single character get transferred properly?
Do binary les still have the same checksum after they have been transferred?

Last modied: Friday, 12 August 2016, 11:39 AM

You are logged in as Priyanka Nalluru (Log out)

CSC8415_2016_2
ABN: 40 234 732 081 | CRICOS: QLD 00244B, NSW 02225M | TEQSA: PRV12081 | Right to Information |
Disclaimer | Privacy | Feedback | Contact us
University of Southern Queensland | USQ is a member of the Regional Universities Network

TwitterFacebook
Youtube
LinkedIn
Instagram
Pinterest
Google+