Networking程序辅导
日期：2023-10-19 07:42
Networks&Operating Systems Essentials 2 (NOSE 2)
Assessed Exercise 1: Networking
Deadline: Week 6 Friday, October 27th 2023 at 16:30
Submission: Moodle
Grading: released via the SoCS LTC system
The aim of this exercise is to have students use the knowledge they’ve acquired in this
first part of the course, in the context of building a networked application. You will be
using the Python socket library to create a simple, yet powerful, file service
application. Your application will consist of two Python scripts: (a) a “server” that
receives and serves client requestsfor filesstored in a local directory, and (b) a “client”
that allows the user to upload/download files from the server, as well as list the files
currently stored on the server side.
Python Sockets
An Internet socket is an abstract representation for the local endpoint of a network
connection. Berkeley sockets is an API for Internet sockets, coined after the first
implementation of sockets appeared in 4.2BSD (circa 1983). Over time, Berkeley
sockets evolved to what is now known as POSIX sockets – an IEEE standard defined
with the aim of maintaining compatibility and providing interoperability between
operating systems. POSIX sockets can be used to communicate using a number of
protocols, including (but not limited to) TCP, UDP, ICMP, SCTP and others.
The basic workflow for setting up a TCP connection to a remote host using POSIX
sockets is outlined in the course lectures and in the 3rd lab; please consult the lecture
slides/recordings and lab handouts. For this assessed exercise you can use all
methods provided by the basic Python socket library (Lib/socket.py). You are not
allowed to use any other networking libraries that act as wrappers for socket.py
(e.g., Lib/socketserver.py, Lib/http/server.py, Lib/http/client.py,
Lib/ftplib.py, etc.). If you are thinking about using a Python library other than
Lib/socket.py, Lib/sys.py or Lib/os.py, please ask us first!
Server
The server will be a Python script, named server.py, executed through the Windows
command line interface. The current working directory of the server (i.e., the directory
from where the server.py script is executed) will be used as the directory where files
will be stored and served from. As your program needs to have write access to said
directory, please make sure that, in your Windows command prompt window, you
first change directory to someplace where you can store files, then execute your
python script from there.
Yourservershould receive, asitssingle command line argument, its port number; that
is, the server should be executed like so:
python server.py
For example, assuming that M: is a drive where you have full write access:
C:\Users\me> M:
M:\> cd some_dir
M:\some_dir> python server.py 6789
On startup, your server should create a TCP server socket, bind it to the user-defined
port number (for the hostname use either “0.0.0.0” or an empty string, so as to bind
to all available network interfaces on your host), report success (i.e., print a single-line
message with its IP address and port number on the console and the text “server
up and running”), and wait for client connections. For every incoming connection
(as returned by socket.accept()) it should read and parse the request from the
client, serve it accordingly, close the connection, report on its outcome (more on this
shortly), and loop back to waiting for the next client connection.
Your server should be able to handle three types of requests:
? Uploading of a file: The client request should include, as a minimum, the
request type and the filename to be used on the server side, and the data of
the file. The server should then create the file (in exclusive creation, binary
mode) and copy the data sent by the client from the socket to the file. To avoid
accidents, the server should deny overwriting existing files.
? Downloading of a file: The client request should include, as a minimum, the
request type and the filename of the file to be downloaded. The server should
then open the file (in binary mode) and copy its data to the client through the
socket.
? Listing of 1st-level directory contents: The client request should indicate the
request type. The server should then construct a list of the names of
files/directories at the top level of its current working directory (e.g., using
os.listdir()) and return it to the client over the socket. For the needs of
this project, your server should not need to handle subdirectories; i.e., all files
served and/or entries returned by os.listdir() should be those at the top
level of the server’s current working directory.
In every case, the servershould report (i.e., print on the console) information for every
request after its processing is over. This report should be a single line including, at the
very least, the IP address and port number of the client, information on the request
itself (type and filename, as appropriate) and its status (success/failure). For failures,
the report should also include an informative message indicating the type of error.
Last, the server should also print informative messages for any other types of errors
encountered throughout its execution (again, please only print a single line per error).
Client
The client will be a Python script, named client.py, executed through the Windows
command line interface and receiving its arguments as command line arguments. The
first argument should be the address of the server (hostname or IP address) and the
second argument should be the server’s port number. The next argument should be
one of “put”, “get” or “list”; these signify that the client wishes to send or receive
a file, or request a directory listing, respectively. For “put” and “get” there should
then be one more argument with the name of the file to upload/download
respectively. That is, the client should be executed like so:
python client.py
For example:
M:\some_dir> python client.py localhost 6789 put test1.txt
M:\some_dir> python client.py localhost 6789 get test2.txt
M:\some_dir> python client.py localhost 6789 list
The client should parse its command line arguments and decide what operation is
requested. It should then create a client socket, connect to the server defined in the
command line, construct and send an appropriate request message, receive the
server’s response, process it, and finally close the connection. The processing of
requests will depend on the request type:
? Upload (“put”) request: The client should, at the very least, open (in binary
mode) the local file defined on the command line, read its data, send it to the
server through the socket, and finally close the connection.
? Download (“get”) request: The clientshould, at the very least, create the local
file defined on the command line (in exclusive binary mode), read the data sent
by the server, store it in the file, and finally close the connection. To avoid
accidents, the client should deny overwriting existing files.
? Listing (“list”) request: the client should, at the very least, send an
appropriate request message, receive the listing from the server, print it on
the screen one file per line, and finally close the connection.
In every case, the client should report information for every request; this report
should be a single line of text including, at the very least, the IP and port number of
the server, information on the request itself (type and filename, as appropriate), and
its status (success/failure). For failures, the report should also include an informative
message indicating the type of error (within the same single line).
Miscellanea
Your client request and server response messages may need to include additional
fields to those outlined above. The design of the application-level protocol (i.e., the
types and formats of exchanged messages, and the exactsemantics and order in which
these messages are exchanged) is left up to you and is indeed a major component in
the marking scheme of this assessed exercise.
As several pieces of the logic will be shared between client and server, you should try
to abstract out the common pieces -- i.e., define functions in a shared module,
imported and used by both client and server. For example:
? send_file(socket, filename): Opens the file with the given filename
and sends its data over the network through the provided socket.
? recv_file(socket, filename): Creates the file with the given filename
and stores into it data received from the provided socket.
? send_listing(socket): Generates and sends the directory listing from
the server to the client via the provided socket.
? recv_listing(socket): Receives the listing from the server via the
provided socket and prints it on screen.
These functions could then be used by both sides; e.g., for a “put” request, the client
will use send_file(…) while the server will use recv_file(…); vice-versa for a
“get” request; the functions for the listings could internally also make use of the file
functions; etc.
Please make sure that your code is well formatted and documented, and that an
appropriate function/variable naming scheme has been used. You won’t be assessed
on the quality of your Python code per se, but a well written implementation is surely
easier to debug (and mark).
What to submit
For this assessed exercise, you are allowed to work on your own or in teams of up to
two (2) students and if the latter both students should be in the same lab group!
Submit two files via the course’s Moodle page: (a) a zip file with your Python source
code files (Source.zip), and (b) a separate pdf file (Report.pdf) with a short report of
2 pages maximum. The report should have a heading stating the full names and
matriculation numbers of the team member(s) and include a detailed description of
the application-level protocol you designed (exact format of the exchanged messages,
their fields and semantics, the order in which these messages are expected to be
exchanged, etc.) and a discussion of the reasoning behind the design of your protocol
and the associated design decisions. Only ONE (1) submission should be done per
team.
How Exercise 1 will be marked
Following timely submission on Moodle, the exercise will be given a numerical mark,
between 0 (no submission) and 100 (perfect in every way). These numerical marks will
then be converted to a band (A1, A2, etc.)
The marking scheme is given below:
? 70 marks for the implementation:
o 15 marks for the implementation of the “list” request type and 25 marks
for each of “put”/”get” request types, broken down as follows:
§ 9 marks for handling the intricacies of TCP communication – i.e.,
that data is streamed from the source to the destination and hence
data sent via a single send()/sendall() call may be fragmented
and received across several sequential recv() calls, or data sent
via multiple send()/sendall() calls may be collated and
returned through a single recv() call. (All request types)
§ 3 marks for handling of connection failures mid-way through the
protocol. (All request types)
§ 2 marks for appropriate logging/reporting. (All request types)
§ 1 mark for parsing of command line arguments. (All request types)
§ 5 marks for correct handling/transferring of binary data (binary
transfer, byte ordering, etc.). (Only for “put”/”get” requests)
§ 5 marksforsupport forstability/security featuressuch as very large
files, 0-sized files, no overwriting of existing files, very long
filenames, etc. (Only for “put”/”get” requests)
o 5 marks for appropriate structure of your code (functions, minimal
repetition of code, informative but not excessive comments, etc.).
? 30 marks for the report:
o 20 marks for the quality of the design of the application-level protocol.
o 10 marks for the discussion of the reasoning/design decisions.
Extension requests:
We will not be responding to individual emails asking for an extension.
- If less than 5 days:
o Request should be initiated by you through the SoCS LTC system :
https://studentltc.dcs.gla.ac.uk/ (you need to be connected to the
School’s VPN)
o Your request should be justified through a good reason of why you
need an extension.
- If more than 5 days:
o Complete a Good Cause Claim, guidelines here:
https://www.gla.ac.uk/media/Media_420013_smxx.pdf
- Last minute requests (i.e., same day, day before the submission deadline)
will not be granted unless a serious emergency (e.g., medical emergency,
serious family emergency) has emerged.
