代做go作业、代写go作业、代做go语言程序作业、代写 go作业
Course Work 1 – Network Application Development
Coursework Weight: 60%
In this coursework, you will develop a number of small networking-based applications. These
are designed to increase your competency in developing socket-based applications, as well as
increasing your familiarity with a number of key technologies and measures. These are in
widespread use, and commonly deployed to evaluate networks and to provide services over
them.
Coursework 1 is split into a number of smaller tasks: ICMP Ping Client, Traceroute Client, Web
Server and Web Proxy. Importantly, the tasks build upon each other; the work you do in Task
1.out completing
any of them. They are intentionally challenging and designed to stretch you.
Task 1.2: Traceroute
The second aspect of this task is to recreate the traceroute tool, again in Python. As
discussed in Lecture 3: Delay, Loss & Throughput, this is used to measure latency between the
host and each hop along the route to a destination. This too uses an ICMP echo request
message, but with an important modification: the Time To Live (TTL) value is initially set to
1. This ensures that we get a response from the first hop; the network device closest to the
host we are running the script on. When the message arrives at this device, the TTL
counter is decremented. When it reaches 0 (in this case at the first hop), the message is
returned to the client with an ICMP type of 11. This indicates that TTL has been exceeded.
As with the previous task, by measuring the time taken to receive this response, delay can
be calculated at each hop in the network. This process can be repeated, increasing the TTL
each time, until we receive an echo reply back (with an ICMP type of 0). This tells us that we
have reached the destination, so we can stop the script.
Implementation Tips
As with the previous task, make sure you think carefully about the logic here. Remember
you can build upon your Task 1.1 implementation, although you should submit two separate
scripts; one for each subtask.
As before, the checksum function included in the skeleton code can be used without
penalty.
The same Python documentation as noted in Task 1.1 will be useful for this task too. Of
particular note is the socket.setsockopt(level, optname, value) function,
which can be used to set the TTL of a socket (and thus the packets leaving it):
https://docs.python.org/2/library/socket.html#socket.socket.setsockopt
Debugging and Testing
As with the previous task, every host on the path to your chosen destination should
respond to your echo request message. In reality, these messages are often filtered, including
within the lab network. As a result, it is especially difficult to test this tool with a remote
host. Instead, it is suggested that you test with a closer endpoint that is reachable:
lancaster.ac.uk. Although the number of hops is small (~5), it can still be used to
demonstrate the working of your application. If you run your script whilst attached to a
different network, such as that at home, your results likely differ. You will also be able to
reach external hosts more easily.
The traceroute utility can be used to confirm the results generated by your own
application. This is installed on the virtual machine if you wish to use it. Be aware that by
default, this tool actually sends messages over UDP instead of ICMP; this is done to avoid
Practical 1 Network Application Development Lent Term, 2018
SCC. 203 Computer Networks 6
the blocking discussed earlier. To force traceroute to send packets using ICMP, the -I
flag can be used. See the Linux man page for more details:
https://linux.die.net/man/8/traceroute
As with Task 1.1, Wireshark can be used to inspect the packets leaving your application.
Comparing these to those created using the traceroute utility will provide you with a
meaningful comparison.
Marking Criteria
The majority of marks will be awarded for ensuring that your implementation behaves in a
way similar to the traceroute utility. This includes providing delay measurements for
each of the nodes between your machine and the chosen remote host. You are expected to
increase the TTL of each message, until you reach this final destination.
Additional marks will be awarded for the following aspects:
Measuring and reporting packet loss, including unreachable destinations
Repeated measurements for each node
Configurable timeout, set using an optional argument
Configurable protocol (UDP or ICMP), set using an optional argument
Resolve the IP addresses found in the responses to their respective hostnames
As before, please note that the features mentioned above are considered supplementary;
you do not have to complete them all, and you can still receive a satisfactory mark without
completing any of them. They are intentionally challenging and designed to stretch you.
Task 2.1: Web Server
For the second task of this practical, you will be building a simple HTTP web server. Web
Servers are a fundamental part of the Internet; they serve the web pages and content that
we are all familiar with. You will be learning more about web servers and the operation of
the HTTP protocol in Lecture 6: Web & HTTP. Fundamentally, a web server receives a
HTTP GET request for an object (usually a file), located on the web server. Once it receives
this request, the web server will respond by returning this object back to the requester.
As with the previous task, we will be using network sockets to build our application and to
interact with the network. The Web Server differs from the ICMP Ping application in that it
will bind to an explicit socket, identified by a port number. This allows the Web Server to
listen constantly for incoming requests, responding to each in turn. HTTP traffic is usually
bound for port 80, with port 8080 a frequently used alternative. For the purposes of this
application, we suggest you bind to a high numbered port above 1024; these are
unprivileged sockets, which reduces the likelihood of conflict with existing running services
on the virtual machine. For interest, application developers can register port numbers with
the Internet Assigned Numbers Authority (IANA), reserving them for their application’s
use:
Practical 1 Network Application Development Lent Term, 2018
SCC. 203 Computer Networks 7
https://www.iana.org/assignments/service-names-port-numbers/service-names-portnumbers.xhtml
The application you build should respond to HTTP GET requests, and should be built to
HTTP/1.1 specification, as defined in RFC2616. These requests will contain a Request-URI,
which is used to define the path to the object requested. For example, a request with a URI
of 127.0.0.1:8000/index.html, will serve a file name index.html found in the
same directory as the Python script itself. The URI is broken down as follows:
127.0.0.1: Hostname of web server
8000: Port number that web server has bound to
index.html: File to be served
On successfully finding and loading the file, it will be sent back to client with the appropriate
header. This will contain the Status-Code 200, meaning that the file has been found OK, and
that it will be delivered to the client as expected. Your implementation needs only serve
files from the same directory in which the Python script is executed.
Implementation Tips
As before, we have provided skeleton code that can be used to aid you in this task. This can
be found on the course’s Moodle page. It contains suggested functions, as well as an
overview of functionality to be implemented by each. These are given as comments and are
to be treated as guidance only. Note that you may have to change the parameters passed
to each function as you advance with the task. An example HTML file (index.html) is
also provided in the same location. The following Python library and its documentation may
also serve as a pointer to helpful functions (the latter will be of particular interest):
https://docs.python.org/2/library/socket.html
https://docs.python.org/2/library/socket.html#socket.socket.accept
As a baseline, your implementation needs only to be single-threaded. This allows a
maximum of one request to be handled at a time.
Debugging and Testing
To test your web server application, you must generate a valid request. There are a number
of tools to achieve this. For example, the wget utility can be used to generate a request
(presuming your web server is running on port 8000):
wget 127.0.0.1:8000/index.html
An equally valid method is to use a web browser, such as the Chromium Web Browser
installed on the virtual machine. Simply point the browser to the same URL:
127.0.0.1:8000/index.html
If you are unsure about what a HTTP request should look like, Wireshark can again be used
to inspect packets. This includes both the HTTP request and response. This will help you
debugging the form and structure of your requests, identifying any issues that may be
Practical 1 Network Application Development Lent Term, 2018
SCC. 203 Computer Networks 8
present. If you are still using Wireshark from the previous task, make sure to remove the
icmp filter! http can be used instead. It will also be necessary to capture packets on the
loopback interface (lo), rather than the external interface (eth0).
If you wish to observe how a Web Server should behave (and examine the packets
generated by such), Python provides a handy way of starting a very simple HTTP server
implementation:
python -m SimpleHTTPServer
Requests to this server can be made using the methods described previously.
Marking Criteria
For this task, you will be awarded marks for a functioning Web Server, capable of handling
requests for content. You should be able to demonstrate that, given a request, the Web
Server will return the correct file, as well as producing a well-formed response header with
protocol version and response code set correctly.
Additional marks will be awarded for the following aspects:
Binding the Web Server to a configurable port, defined as an optional argument
When
