Microsoft Word – assignment3sol.docx
CMPT 471: ASSIGNMENT 3
YOU MAY WORK IN GROUPS OF 1-2 STUDENTS FOR THIS ASSIGNMENT
PROBLEM 1: 60 points
Submit the code for your client and your server to the course management system. You may use C or C++
to develop the server and clients, but you MUST use the C socket library (not a C++ socket library). Your
code must run in the CSIL LINUX environment.
40 points for a dual stack file transfer server (sequential operation)
35 points for the points for a dual stack TCP echo client (sequential operation)
60 points given for correctly functioning server (32 points) and client (28 points).
o It is much better to submit a consistently working code that satisfies some requirements than a
partially working (unstable) code that sometimes satisfies more requirements. If your code
crashes or hangs during one of the tests you will receive a substantial deduction from your
grade (~5-10 points).
15 points given for explanation and/or detailed comments explaining how the client (7 points) or
server (8 points) functions
If you submit a sequential server instead of an instance server you can receive a deduction of 15 points
If you submit an IPv4 only client and server you can receive a deduction of 25 points.
Write a dual stack TCP file transfer client and a dual stack TCP file transfer server. You may begin with
the sample code provided if you wish. The sample code is an echo client and server (not optimally
implemented). The sample server is an instance server that created a process that is a copy of the original
server to service each request. Specifications of each client and the server are given below.
For smoother and easier development you may wish to write a client and sequential server for IPv4 only
first, then add the support for IPv6, then convert to an instance server.
GENERAL SPECIFICATIONS
1. Your code must be written in C or C++ and must run in the CSIL LINUX environment
2. You may assume that files to be transferred are in the same folder as the TCP file transfer server.
3. IPv4 requests and IPv6 requests can arrive at the server in any order, you MAY NOT assume that they
alternate.
4. The instance server will create a new copy of itself to process each file transfer. You may create the
copy as a new process OR as a new thread, the sample code produces a new process.
5. If a client request is made using the IPv6 address of the server then the request and the file will be
transferred using IPv6.
6. If a client request is made using the IPv4 address of the server then the request and the file will be
transferred using IPv4.
7. Your file transfer server should be able to respond to both IPv4 and IPv6 requests. It should respond
to requests from IPv4 and IPv6 clients sequentially (in any order) or, for the instance server,
concurrently (at the same time) without restarting the server.
8. Your TCP client and server should use an internal buffer with a size that is specified as a command
line argument. The size of the buffer will be the maximum size of the block of data that can be carried
in a single TCP segment. The size of the buffer must be the same in the clients and the server. This
buffer will be referred to as the send/receive buffer. This is NOT the sliding window buffer.
9. Your client should take as command line arguments the server IP address and port number, the client
IP address, the filename of the requested file and the size of the send/receive buffer in that order as
command line arguments,
10. Your servers should take as command line arguments the server IPv4 port number, the sever IPv6 port
number and the size of send/receive buffer. Arguments should be in the order mentioned in the
previous sentence.
TCP file transfer client specifications:
Constructs a message to send to the file transfer server that will indicate the file that should be
transferred.
If the command line arguments for the IP address of the server is an IPv4 address creates an IPv4
socket, otherwise creates an IPv6 socket.
Sets the MTU of the new socket (from buffer size)
Connects to the server
Sends the constructed message to the file transfer server.
If the packet contains the error message “COULD NOT OPEN REQUESTED FILE”
o Clean up and terminate the client
Otherwise the packet will contain the message “FILE SIZE IS xxxxx bytes” where xxxx is the size
of the file in bytes.
o Extract and save the number of bytes
o Open a file with the same name as the file requested on the client host (in the same folder as
the client is running)
o If the file cannot be opened print the error message “COULD NOT OPEN OUTPUT FILE”,
clean up and terminate the client.
Until all data in the file has been received.
o A packet of data is received
o The data is removed from the packet and written to the file on the client.
o The socket waits to read the next packet that arrives.
Duplicate data should not be added to the file
After execution of the client this file on the client host should be identical to the file on the server host.
File transfer server specifications:
1. The server should create an IPv4 TCP socket and an IPv6 TCP socket.
2. The server should use the values in the command line arguments to bind the IPv4 and IPv6 sockets to
the correct port and IP address.
3. The server should convert the IPv4 and IPv6 sockets to listening sockets.
4. The instance server should spawn a copy of itself to manage each TCP connection request.
5. Each copy should be a separate process or a separate thread.
6. Each copy of the TCP echo server should
a. Accept a connection request.
i. If the connection request is for the IPv4 port connect to the IPv4 socket
ii. If the connection request is for the IPv6 port connect to the IPv6 socket
b. Close the listening sockets
c. Receive the request for the file to transfer.
d. Extract the filename from the request and attempt to open the file
e. Should send a message to the client
1. If the file could not be found or not be opened the message should be
“COULD NOT OPEN REQUESTED FILE”
2. If the file is open and ready to send the message should be
“FILE SIZE IS xxxxx bytes”.
f. If the file cannot be found or cannot be opened then clean up and terminate the copy of the
server.
g. Send the contents of the file one segment at a time. Wait approximately 1 second between
sending successive segments.
h. Close the file
i. Terminate the copy of the server
Default values:
For both the client and the servers the IPv4 port number should default to 33455 if no port number
is given. And the IPv6 port number should default to 33446
For both the client and the server the IP address should default to the localhost address
For both the client and the servers the send receive buffer size should default to 1440 for IPv4 and
1280 for IPv6 if no size is given.
The default filename will be fileToTransfer
If no arguments are given your clients and server should print a message indicating the command
line inputs/options for running the program.
Test your clients and server to assure that they function correctly both when running on the same machine
(loopback) and when running on different machines. Use the dual stack network (lab1-06 to lab1-010)
for testing.
case 1: loopback on august, run client and server with no argument values
—–2 points for description of command line input
—– 3 points: all defaults are implemented for IPv4.
—– 2 points: non default filename supported
case 1: loopback on august, run client and server (on host august) with input file not
available
—- 1 point: can access defaults without typing in values
—– 1 point: connects
—– 1 point: produces could not open message
—– 1 point: server is still running after request
Repeat case 1 for IPv6 (points assigned as for IPv4 above)
case 2: loopback on august . Use non default filename, run client and server providing
all other default values as command line arguments (on host august)
—– 2 points: No missing or extra text in copied file (also deduct if no file
created/updated)
—– 2 points: filesize message in client
—– 2 points: transferred using IPv4 addresses (using Wireshark to see transfer to
confirm)
—– 2 points: client terminates cleanly on all runs in case 1 and case 2
Repeat case 2 for IPv6
Transmission of requested (non default filename) file from august (server) to autumn
(client). Run for IPv4 and then IPv6. For each run consider
—– 1 point: generating Filesize message is at server
—– 2 points: if extra/missing text in copied file
—– 1 points: if not transferred by IPv4 (IPv6 2nd run)
9 points: run several different file requests in any order without problems
9 points: send two requests rapidly and see that they are served simultaneously
5 extra points deduction if not a instance server
5 extra points off if no IPv6
PROBLEM 2 (31 points):
EXPERIMENT
Choose one host on each of the four networks in the virtual lab. Open a Wireshark window on each of
these hosts to capture ICMPv6 datagrams. Next, select one additional host on net 17 (host A) and one
additional host on net 18 (host B). Ping each of the global IPV6 address of host B from host A. Next, use
host B to ping each of the IPv6 addresses of host A. that begin with fdd0. Capture at least 2 echo request
echo reply pairs for each address pinged. Save each of your capture files for analysis and submission.
Since IPv6 is being introduced into the internet gradually and must operate in the internet along with
IPv4 there are a number of transition strategies. One of these is to use tunneling to enable IPv6 traffic
to pass through IPv4 only networks. Several types of tunneling are available.
QUESTIONS AND ANALYSIS FOR EXPERIMENT:
a) [10 points] Examine the /etc/network/interfaces file on router december. Briefly explain what
each line that effects eth2 in the file does.
1 points for showing the portion of the file being considered or for clearly
explaining what portion is used
The portion of the
/etc/network/interfaces file that
relates to eth2 is shown here
The command auto eth2 indicates that the configuration will be automatically run on restart
or boot (1 point)
The command that starts with “iface” indicated that the a static address is being provided for
eth2 (the inet, inet6 indicates a static address for IPv4 or IPv6 respectively) (1 point)
For IPv4 The IPv4 interface address(½ point), the net mask(½ point), the network address(½
point), the broadcast address(½ point) and the gateway(½ point) for the default route(1
point) are specified one per command. All addresses are given in dotted decimal
For IPv6 the interface address, the network address and the CIDR prefix length (number of one
bits in the CIDR network mask) are specified as address(½ point), network(½ point) and net
mask(½ point) respectively
The dns-nameserver line gives the iP address of the single DNS server used in the virtual lab
(1 point)
The dns-search command is used to construct the search line in the resolv.conf file on the host.
(1 point) (search commands for different interfaces are combined to give the search line in
resolv.conf)
The IPv6 command “modprob” checks to make sure the interface is configured for IPv6, it loads
needed IPV6 modules if they are not already present.(1 point)
b) [8 points] Which lines in the /etc/network/interfaces file are used to support 6in4 tunneling? Show the lines
below for the hosts at both ends of the tunnel. What IP addresses are used for the ends of the tunnel? Why is
the MTU of 1460 chosen for the packets travelling through the tunnel? List the lines in the
/etc/network/interfaces on router file are used to support 6in4 tunneling?
1 point for supplying the lines being discussed
What IP addresses are used for the ends of the tunnel?
The block of information shown in b) is also used as evidence in this question.
1 point for the blocks of information above (or description of what is contained in
the block) The block for either end of the tunnel is acceptable
The addresses of the ends of the tunnel are 172.16.1.1 and 172.16.1.2
2 points for the addresses at the ends of the tunnel (1 each end)
Why is the MTU of 1460 chosen for the packets travelling through the tunnel in the virtual lab?
The MTU of 1460 is chosen so that the packets travelling through the tunnel should not
exceed the MTU of 1500 which is the maximum for Ethernet.
The limit set in RFC 4213 on 6 in 4 encapsulation is 1280-1480 (1 point)
“A node using static tunnel MTU treats the tunnel interface as having a
fixed-interface MTU. By default, the MTU MUST be between 1280 and 1480
bytes (inclusive)” (1 point)
This assumes a 20 byte header. The protocol also discusses that fragmentation with MTU
greater than 1280 can be an issue (longer headers). Since some options may be present and in
the case of the virtual lab these options are less than 20 bytes the MTU value 1460 was chosen
to prevent fragmentation caused by the inclusion of a small number of options in the IPv4
header. 2 points
c) [6 points] Examine the IPv4 datagrams carrying echo requests and replies through net 16. Briefly
discuss what you would expect a 6in4 encapsulated packet to look like and use your captured
datagrams to help you illustrate your explanation. You must site evidence from your capture file.
Evidence showing the headers present in one of the 6 in 4 packets
captured (2 points)
A 6 in 4 packet will be the IPv6 packet seen on the sending network, encapsulated in an IPv4
header. (1 ponts) In the lines shown above you can see an IPv6 header inside an IPv4 header
as you would expect. (1 ponts) The IP addresses and ID of the IPv6 packet in the tunnel match
those of the packet on its way to the tunnel. (1 ponts)
The IPv4 packet will be sent from the address of one end of the tunnel to the address at the other
end of the tunnel. (1 ponts) This is what is seen in the IP source and destination addresses for
the IPv4 header illustrated above.
For example the packet above is traveling from eth1 of january (172.16.1.1) to eth1 of december
(172.16.1..12) (according to source and destination IPv4 addresses.)
d) [2 points] Packets destined for which networks travel through the tunnel through network 16 (an
IPv4 only network). No evidence is necessary
Only packets destined for networks 8018 and 8017 travel through the tunnel.
PROBLEM 3: (10 points)
Consider computation of a TCP checksum. Assume that although the checksum field in the segment has
not been set to zero, the result of computing the checksum is zero. What can you conclude?
You can conclude that the checksum field contains the TCP checksum.
Explanation
Consider a TCP segment, the checksum for the TCP segment is determined by calculating a ones
complement sum of all the 16 bit words in the TCP pseudo header, the TCP header and the data
in the TCP segment, then taking the ones complement of the sum.
Remember that ones complement subtraction is implemented by a ones complement addition of
the ones complement of the number to be subtracted
BABA and that BB is a string of ones and therefore BB is 0.
Let the ones complement sum of the 16 bit words (including the checksum field) whose ones
complement sum is to be calculated be denoted
SumWswwwwww pnn 1321 , and the resulting checksum be denoted
SumWs . Let ones complement sum, not including the checksum field be Sum, and the resulting
checksum be Sum . Assume that the word containing the 16 bit checksum field is nw . Then
nwSumSumWs
We are given that
01321 SumWswwwwww pnn
so
11321 SumWswwwwww pnn (a string of 16 ones)
Therefore
1 nwSumSumWs
But we know that 1 BB which implies the Sum must be nw
If Sum = wn then
The checksum field of the segment contains the checksum (calculated using the normal
algorithm setting the checksum field to zero) of the segment.