Section 1 (40 points) Short Answer Questions1 CPSC 3600 section 002 HW #1 Solutions Fall 2017 Last revision: 9/29/2017 You must work on this homework individually !! Section 1 (40

1

CPSC 3600 section 002 HW #1 Solutions

Fall 2017

Last revision: 9/29/2017

You must work on this homework individually !!

Section 1 (40 points) Short Answer Questions

Question 1.1 (5) List the layers from the OSI seven layer network model that apply in a

TCP/IP network. Provide a 1sentence summary of each layer in a TCP/IP context.

Solution: First 3 are necessary for full credit

Application layer: Protocols at the top level of the stack specify how applications

are to interact when they communicate.

Transport layer: Protocols in the Transport layer provide for communication from

an application program on one computer to an application program on another.

Network layer- The Internet layer (referred to as Internet Protocol or IP)

specifies how two computers communicate across a network.

Link layer: While not formally a part of TCP/IP, the link layer applies in a

TCP/IP network. The goal of TCP/IP is to operate over any link. The link layer

deals with sending and receiving network packets between nodes that are directly

connected.

Physical: Again, not formally a part of TCP/IP but it applies in a network. The

physical layer provides the rules and data formats that define the data

communications over a particular transmission medium.

Question 1.2 (5) Assume two nodes communicate directly over a physical layer. Explain

the difference between the channel bandwidth and the baud rate in a context where the

two nodes communicate directly over a physical layer.

Solution: The term bandwidth has different definitions depending on the context.

A ‘channel bandwidth’ might refer to the ‘analog bandwidth’. This corresponds to the

‘spectrum range’ of the communications channel. So it is the difference between the

highest and lowest frequencies that can operate over the channel. Another way to state

this is that the channel bandwidth is the fastest continuously oscillating signal that can be

sent over the channel. It is measured in cycles per second or Hertz (hz).

The baud rate is a measure of how the communications method actually uses the channel

bandwidth. Therefore, the baud rate is the transmitter’s maximum signal rate. The baud

rate will be at most the channel bandwidth. However, to ensure robust communications

over possibly noisy channel conditions, the baud rate is likely lower than the channel

2

bandwidth. A measure of the efficiency of a communications system is how close the

baud rate comes to the channel bandwidth.

The baud rate along with the number of bits that are ‘encoded’ in each information

symbol determines the maximum rate at which digital data can be transmitted and

received. This rate is referred to as the channel capacity or sometimes called the data

rate.

Data rate = baud * log2(#signal levels)

In general, the number of data bits that can be encoded is the log base 2 number of signal

levels. Let’s say the transmission is a simply voltage – of either positive voltage or a

negative voltage. There are 2 signal levels per symbol which encodes 1 bit of data. If

the transmission were able to provide 4 unique voltage levels (-5, -2, +2, +5), this

increases the number of data bits to 2.

Data bits Signals

0 0 -5

0 1 -2

1 0 +2

1 1 +5

N possible unique combinations of energy can map to log2(N) unique sequences of 1’s

and 0’s.

A more useful definition of data rate would be to modify the theoretic data rate to reflect

the rate at which link data can be transferred. This accounts for the physical layer

overhead which can be significant especially over wireless channels.

Bandwidth has a different meaning when the perspective is at network layers above the

physical layer. In the context of the physical layer, term bandwidth relates to the

spectral width of electromagnetic signals. In the context of data networks, the term

bandwidth quantifies the data rate that a network link or a network path can transfer.

Further complications arise in defining bandwidth related to the amount of the channel

capacity that is consumed by overhead.

Other variants of the bandwidth concept include:

Effective data rate: the physical layer data rate adjusted for the amount of

physical layer overhead.

Link rate: The rate at which a link layer protocol can send and receive data from

higher layers. This takes into account the link layer overhead.

Network bandwidth : the rate that a network can send and receive data.

Available bandwidth : A network (large or small) might not be able to provide to

a particular user all of capacity as there might be congestion, channel errors, or

3

network service provider policy limits. At a given time instant, the amount of

capacity that can be allocated to a user is referred to as the available bandwidth.

Throughput: This usually refers to the rate at which data can be transferred

between two endpoints. It might assume transport layer overhead (or not).

Goodput: To clearly limit the measure to application data, the term goodput can

be used.

Question 1.3 (5) New automobiles sold in the United States will soon be required to

support wireless communications using a form of WiFi. There are seven channels

available to support vehicle-to-vehicle communications. The bandwidth of each channel

is 10Mhz. In the ‘best conditions’, it uses a modulation/demodulation based on QAM-64

which uses 64 signal levels per symbol. What is the maximum data rate in these ‘best

conditions’ ? Please state any assumptions you might make for your answer. Hint:

look up the Nyquist theorem.

Solution:

The Nyquist theorem provides the best case theoretic data rate over a channel of a given

bandwidth when used with a particular modulation method.

Data rate: 2 B logK = 2 * 10Mhz * log k where k is the number of signal levels. (64 in

this case).

D = 20,000,000 * 6 = 120 Mbps

The theoretic data rate needs to be adjusted to account for overhead. For this example, the

maximum usable data rate is 27 Mbps.

Further, to account for the effects of possible bit errors caused by channel impairment,

the Shannon theorem specifies the maximum data rate that could be achieved over a

transmission system that experiences noise. The signal to noise ratio (SNR) is a measure

a receiver observes as it attempts to differentiate the signal (from the sender’s

transmission) that arrives at the receiver from noise.

C = B log2 (1 + S/N) where C is the effective limit on the channel capacity in bits per

second, B is the bandwidth, and S/N is the signal-to-noise ratio.

Question 1.4 (5) In a connected vehicle scenario as described in the previous question,

applications running on vehicles can chose to use higher order modulation (64QAM) or

lower order modulation (BPSK or QPSK). Why might a connected vehicle application

transmit application messages using a lower order modulation such as QPSK rather than

4

a higher order modulation (which offers higher data rates than lower modulations) such

as 64 QAM?

Solution:

While higher order modulations offer higher data rates, they become more sensitive to

noise and channel impairments. CV applications generally do not send lots of data and

do not need high data rates. Reliability, quantified by packet loss rates and robust

connectivity over longer distances, is much more important.

Question 1.5 (6) When transmitting a 32-bit 2’s complement integer in big-endian order,

when is the sign bit transmitted (relative to other bits in the 32bit Integer). Please state

any assumptions you make.

Solution: Remember, two’s complement uses the most significant bit as the sign. To

invert, invert each bit and add one.

As an example, an integer of value 2 in hex is: 0x00000002.

To find the negative (i.e., to invert) we invert each bit and add 1.

So an integer of value -2: 11111111 11111111 11111111 11111110 which in hex is

0xFFFFFFFE.

One a big endian, the most significant octet is sent first. How an octet is sent over a

physical medium is dependent on the medium. For a link such as an Ethernet, data in

octets are sent serially starting with the most significant bit. There are other physical

layers that are parallel in nature (anyone remember the parallel port on a PC ? ).

For an Ethernet, the sign bit is sent first

Question 1.6 (5) From the kurose text, Review question R12. In the 7th edition, this

question is on page 68 and begins “What advantage does a circuit-switched network

have…”

Solution:

A circuit-switched network can guarantee a certain amount of end-to-end bandwidth for

the duration of a call. Most packet-switched networks today (including the Internet) cannot

make any end-to-end guarantees for bandwidth. FDM requires sophisticated analog

hardware to shift signal into appropriate frequency bands.

5

Question 1.7 (10) From the Kurose text, review question R13. In the 7th edition, this

question is on page 68 and begins “Suppose users share a 2 Mbps link….”

a) 2 users can be supported because each user requires half of the link bandwidth.

b) Since each user requires 1Mbps when transmitting, if two or fewer users transmit

simultaneously, a maximum of 2Mbps will be required. Since the available

bandwidth of the shared link is 2Mbps, there will be no queuing delay before the

link. Whereas, if three users transmit simultaneously, the bandwidth required

will be 3Mbps which is more than the available bandwidth of the shared link. In

this case, there will be queuing delay before the link.

c) Probability that a given user is transmitting = 0.2

d) Different ways to do this. Easiest is to define three events (E1, E2, E3) to represent a

user transmitting. The P[Ei] is 0.2. Define an event E that represents when all three users

are transmitting. So the Event E is equivalent to E1&E2&E3.

P[E]=P[E1]P[E2]P[E3] which is 0.2*0.2*0.2 = 0.008

Another way to do this is to model the situation as a Bernoulli event. The event is if the

user is transmitting – it’s either yes or no. And the probability of a success(p) is 0.2. We

want the probability of 3 successes in 3 trials :

Probability that all three users are transmitting simultaneously = 333 13

3

pp

= (0.2)3 = 0.008.

Since the queue grows when all the users are transmitting, the fraction of time during

which the queue grows is equivalent to the probability that all three users are transmitting

simultaneously. This is 0.008.

Section 2 (30) Analyzing ping results

Use the ping program on your VM with one of the following hosts: 202.58.60.194 or

202.58.60.194. You can use any other host as long as it is located outside of the US

(or….to the best of your ability, you think it is located outside the US). Use traceroute

or other tools to help estimate the physical location. I’ll refer to the destination node as

the ‘server’. Please do these two parts of this question.

Question 2.1 (10 points)

6

Run ping between your VM and the server for at least 1 hour. Redirect standard

output to a file.

Do this twice. Once in the evening (normally the Internet’s busy time) and once

earlier in the day (or late at night). So you will collect two data files: ping1dat

and ping2.dat.

Ping invocation example (NOTE: this involves a very short path- you are to

find/use a path that goes outside the US): ‘ping -D 152.1.0.36> ping1.dat’

o Specify the destination address as an IPV4 address in dotted decimal

notation.

o Specify the –D parameter so that a timestamp is appended to each sample

Results:

o Copy and paste the ping summary statistics to your homework submission.

o Copy and paste the results from traceroute to your homework submission.

Run ‘traceroute server’, if that does not appear to work, try ‘sudo traceroute –I

server’. Cut and paste your results to your homework submission. The purpose

is simply to verify that the path between the ping program endpoints appears to

be outside the US.

Example result ‘traceroute –I 152.1.0.36’ (Running traceroute 152.1.0.36 does

not work- just see wildcards for 64 iterations before giving up). Note- you can

also ask traceroute to show the domain name of each router- this might give

further clues as to if the path travels outside the US. traceroute to www1.csc.ncsu.edu (152.1.0.36), 64 hops max

o 1 10.0.2.2 0.005ms 0.003ms 0.002ms

o 2 130.127.3.114 14.690ms 25.637ms 15.252ms

o 3 130.127.3.6 13.278ms 17.736ms 18.978ms

o 4 205.186.62.9 19.742ms 14.194ms 15.338ms

o 5 205.186.63.2 18.224ms 15.144ms 31.125ms

o 6 143.215.193.2 17.234ms 15.278ms 16.049ms

o 7 198.71.46.170 22.189ms 38.032ms 22.835ms

o 8 128.109.9.217 25.090ms 24.523ms 26.389ms

o 9 128.109.18.110 26.197ms 24.992ms 30.577ms

o 10 152.1.6.253 27.822ms 28.429ms 27.553ms

o 11 * * *

o 12 * * *

o 13 152.1.0.36 43.842ms 39.613ms 32.689ms

We can interpret the traceroute result as follows

o There are at least 13 hops between my VM and the server.

o Each traceroute line shows the response from the next hop router. By

default, traceroute contacts each router (hop by hop) three times.

The three times in each line represent the RTT from the three contact

attempts with the router.

o We do see an increase in the avg RTT as we move further away from

the client. Not that sometimes we might see a hop reflect a larger

RTT than the next hop router. This usually is due to the fact that

some routers handle packets that require special processing (such as

7

when the traceroute client contacts the router) on a low priority basis.

Routers typically give priority to forwarding traffic and then respond

to IP control/signaling messages such as ICMP or IP options at a

lower priority.

o The asterisks at hops 11 and 12 are probably due to a firewall rule.

Solution:

Performed ‘ping –D 202.58.60.194 > ping1.dat ‘ two times.

The first result is from a session during the early afternoon

-- 202.58.60.194 ping statistics ---

8880 packets transmitted, 8857 received, 0% packet loss, time 8893241ms

rtt min/avg/max/mdev = 236.538/244.049/500.643/8.191 ms

The second result was from an evening. The evening session experienced packet loss-

there were errors in the output file indicating that the client received ICMP error

messages of ‘Destination Host Unreachable’ and ‘Destination Network Unreachable’.

These might be due to network failures caused by routing or at the destination endpoint.

Note that the Host Unreachable message contains a private IP network. If you do

traceroute every couple of hours you are likely to see frequent path changes.

1504274996.726364] 64 bytes from 202.58.60.194: icmp_seq=5393 ttl=230 time=246 ms

[1504275010.528146] From 100.46.135.149 icmp_seq=5406 Destination Host Unreachable



[1504275025.648658] From 10.0.2.2 icmp_seq=5422 Destination Net Unreachable

[1504275026.899616] 64 bytes from 202.58.60.194: icmp_seq=5423 ttl=230 time=250 ms










Results from traceroute:

traceroute -I --resolve-hostnames 202.58.60.194

traceroute to 202.58.60.194 (202.58.60.194), 64 hops max

1 10.0.2.2 (10.0.2.2) 0.116ms 0.004ms 0.016ms

2 130.127.3.114 (130.127.3.114) 18.060ms 14.384ms 12.629ms

3 130.127.3.6 (sox-atl.clemson.edu) 12.907ms 15.031ms 11.941ms

4 130.127.3.17 (130.127.3.17) 14.279ms 13.852ms 27.553ms

5 205.186.224.81 (205-186-224-81.generic.sclightrail.net) 12.323ms 12.285ms 12.493ms

8

6 64.57.21.214 (64.57.21.214) 15.878ms 18.657ms 15.643ms

7 64.57.21.213 (et-10-0-0.1190.rtr.ashb.net.internet2.edu) 30.790ms 26.441ms 29.570ms

8 162.252.70.68 (et-0-3-0.4079.sdn-sw.ashb.net.internet2.edu) 29.563ms 27.652ms 28.026ms

9 162.252.70.61 (et-7-1-0.4079.rtsw.chic.net.internet2.edu) 39.216ms 38.544ms 37.819ms

10 198.71.47.207 (et-3-1-0.4070.rtsw.kans.net.internet2.edu) 49.143ms 49.999ms 50.596ms

11 162.252.70.10 (et-8-0-0.4079.sdn-sw.denv.net.internet2.edu) 61.687ms 59.642ms 61.010ms

12 162.252.70.9 (et-4-1-0.4079.rtsw.salt.net.internet2.edu) 68.711ms 71.853ms 69.620ms

13 162.252.70.30 (et-7-0-0.4079.sdn-sw.lasv.net.internet2.edu) 77.794ms 77.533ms 76.648ms

14 206.223.123.199 (lsan0.tr-cps.internet2.edu) 87.122ms 95.621ms 90.589ms

15 206.223.123.11 (gi1--1.wil04.net.telstraglobal.net) 93.840ms 89.658ms 88.935ms

16 202.84.253.85 (unknown.telstraglobal.net) 83.253ms 78.546ms 79.031ms

17 202.84.136.210 (i-0-1-0-52.sydo-core04.bx.telstraglobal.net) 214.127ms 218.193ms 219.915ms

18 203.50.13.93 (bundle-ether3.oxf-gw10.sydney.telstra.net) 217.255ms 221.386ms 214.146ms

19 203.50.6.95 (bundle-ether2.oxf-gw11.sydney.telstra.net) 222.612ms 213.199ms 219.054ms

20 203.50.6.92 (bundle-ether1.chw-core10.sydney.telstra.net) 224.481ms 216.514ms 217.920ms

21 203.50.11.125 (bundle-ether8.exi-core10.melbourne.telstra.net) 227.063ms 229.476ms 225.219ms

22 203.50.11.92 (bundle-ether5.way-core4.adelaide.telstra.net) 249.574ms 243.666ms 243.967ms

23 203.50.120.31 (tengigabitethernet7-1.way21.adelaide.telstra.net) 240.473ms 241.569ms 241.253ms

24 165.228.205.218 (te1-4.brdr1.hostworks.net.au) 238.718ms 238.162ms 240.583ms

25 * * *

26 * * *

27 202.58.60.194 (202.58.60.194) 248.632ms 239.876ms 240.315ms

Question 2.2. (20 points) Plot the probability distribution of each data set. There are

different ways to do this. You do not need to submit the scripts or tools you used- just

document in your HW submission how you did this. Your submission should show each

distribution separately. One method is:

Step 1: Using a script/program, process each ping output data file

(ping1.dat and ping2.dat) and create two files that contain two fields: the

timestamp and the RTT. Let’s refer to these files as RTT1.dat and

RTT2.dat. (UPDATE: If you want, you can create a single column data

file that contains just the RTT sample).

Step 2: We want to plot the distribution of the RTT from each of the

reduced data files. You can do this with excel, matlab, R, ….

o The plotDataPDF.m matlab program will work (link is on our web

page). Make sure the data file is in the same directory as the

matlab script. You will need to edit the matlab file to load the

correct data file and to adjust if the data is one or two columns. In

a matlab command window”

plotDataPDF(1,500000,.5)

The parameters are: plotmode: value 1 is to plot PDF,

maxXValue sets the max RTT sample to 500000

microseconds, maxY sets scale of Y axis to [0,0.50]

Results: Include the two plots in your HW submission. Very briefly,

interpret the results. In your opinion, what conclusions can you draw

from each figure? As best you can, explain any significant differences

between the two data sets (based on the visualizations)

9

Solution:

Given the ping1 and ping2 results, the bash scripts adata1.sh or adata2.sh can be used as

follows : ./adata1.sh ping1.dat “time=” “ ms” ping1Results.dat

Either of the two pipelines will also work:

cat ping1.dat | grep -o "time=[0-9]*[.]*[0-9]* *" | sed "s/time=//g" > RTT1.dat

cat ping1.dat | grep -o "time=[0-9]*[.]*[0-9]* *" | awk 'BEGIN {FS = "="}{printf("%f\n",$2)}' > RTT1.dat

The following bash script was made available. Run it ‘./goData.sh ping1.out 1’ Lines

27 and 34 are the key – these actually translate a file that contains output from ping (lots

of text per line) to a data file that is either just the RTT (in ms’s) or the timestamp and

RTT.

1. #!/bin/bash

2. usage () {

3. echo "Usage: goData.sh [dataFile] [mode]"

4. echo " dataFile: ping output file"

5. echo " mode: mode 1 produces single RTT data column, mode 2 produces two columns

:timestamp RTT "

6. echo " Example: ./goData.sh ping1.dat 1 > RTT1.dat "

7. }

8. INTEGER_REGEXP='^[1-9][0-9]*$'

9. MODE_REGEXP='^(1|2)$'

10. # ensure 3 args were passed

11. if (( $# != 2 )) ; then

12. echo "[ERROR] missing operand"

13. usage

14. exit -1

15. fi

16. myFile="$1"

17. mode="$2"

18. # ensure mode is either 1 or 2

19. if ! [[ "$mode" =~ $MODE_REGEXP ]] ; then

20. echo "[ERROR] mode must be either 1 or 2"

21. usage

22. exit -1

23. fi

10

24. #[1504138864.182816] 64 bytes from 202.58.60.194: icmp_seq=2 ttl=237 time=241 ms

25. #Use grep to search each line for strings like ...time=237", pass what match to awk to print the

second field

26. if [[ "$mode" == 1 ]] ; then

27. tail -n +2 $myFile | head -n -3 | grep -o "time=[0-9]*[.]*[0-9]*" | awk 'BEGIN {FS =

"="}{printf("%f\n",$2)}'

28. fi

29. #[1504138864.182816] 64 bytes from 202.58.60.194: icmp_seq=2 ttl=237 time=241 ms

30. #Instead of grep, we use sed to find and replace three strings for an empty string-

31. # The strings: open and close brackets surrounding the timestamp, and the 'time='.

32. if [[ "$mode" == 2 ]] ; then

33. # tail -n +2 $myFile | head -n -4 | sed 's/\[//g' | sed 's/\]//g' | sed 's/time=//g' | awk '{printf("%f %d

\n",$1, $8)}'

34. tail -n +2 $myFile | head -n -4 | sed 's/\[//g;s/\]//g;s/time=//g' | awk '{printf("%f %f \n",$1, $8)}'

35. fi

I generated the PDF figures with matlab:

plotDataPDF(1,500000, 0.50)

Figure Q2-1A visualizes the distribution of ping RTT results on a day early in the

afternoon. Presumably this is during a non-peak time in the Internet. The distribution

shows a single mode around 244 ms. The summary stats were:

rtt min/avg/max/mdev = 236.538/244.049/500.643/8.191 ms

If we consider the RTT as a random variable, the avg of the samples approximates the

true mean. The distribution illustrates the randomness associated with the random value

X. The range of possible values for X is [236,500] with the majority within the range of

the avg +- a standard deviation [228,244] ms. The second data set was obtained in early

evening and presumably represents a busy time for the Internet. Figure Q2-1B shows the

values are spread over a larger range. Unfortunately I do not have the ping summary

stats as the link dropped in the middle of taking the data.

11

Figure Q2.1A. Measurement-based Probability Distribution during non-peak hours

Figure Q2.1B. Measurement-based Probability Distribution during peak hours

12

Section 3 Sockets Programming (30 points)

You should get familiar with the UDPEcho program (V1-2 in the code examples). You

will be making two functional enhancements to this program. Also, you will be

validating these changes. I refer to these two tasks as part 1 (the two functional

enhancements) and part 2 (the validation) of this question.

Summary of UDPEcho

Download the code – run the client and server with no parameters to get the usage

information. Look over the source code to get familiar with the details. The program is

a very is a simple UDP client/server program. It is similar to the ping program, except

instead of ICMP it uses the UDP transport protocol.

Example usage in the following diagram is the client runs on Host1 and the server runs

on Host2. Let’s assume the IPv4 address of Host2 is 130.127.48.144 and the server is to

use port 5000. The client is instructed to use a message size of 1000 bytes and to perform

10 iterations.

Host1 ---- network----- Host2

At Host2, issue: ./server 5000 129

At Host1, issue: ./client 130.127.48.144 5000 1000000 1000 10 129

The server parameters:

Server side port number

Debug Flag - controls the amount of information displayed to standard out by the

server. The parameter conveys two logging settings: The 8’th bit of the lowest

octet specifies if the server is to log iteration samples to the file EchoServer.dat (a

‘1’ is yes). The lower 7 bits encodes the debugLevel which controls how much

tracing information is displayed to standard out. A value of 0 displays errors, a

value of 1 displays start and stop information, a value of 2 displays iteration

results and a value of 3 displays debugging information. Note that the original

code does not appear to correctly deal with a value of 2. If you want to see

information related to each iteration (as perceived by the server), specify the

debugFlag to be 129. This will create EchoServer.dat file. This file format is

based on the following fprintf in the server code: o fprintf(newFile,"%f %d %d %d %d %d\n",

curTime,RxSeqNumber,recvMsgSize,largestSeqRecv, receivedCount,errorCount);

The client parameters:

Server IPv4 address as a domain name or in dotted quad format

Server port : specifies the server port

Iteration delay: Number of microseconds between samples

13

Message size: specifies the number of application bytes to place in each message.

In order to ensure a message fits in one IP packet, you should assume a message

size can not exceed 1472 bytes.

Number iterations: specifies the number of iterations (i.e., data samples) to

perform (or obtain).

Debug flag - Same as the server parameter except the sample log file is RTT.dat.

The client sends a message of the given size and then waits for a timeout amount of time

for the echo’ed message. The client places a sequence number (32 bit unsigned int) in

each message, beginning with 0 and incrementing by 1 with each new iteration. The

remaining data values are set to zero. If the iteration is successful, the echo’ed packet is

received by the client host and unblocks the client application with the received message

placed in the applications receive buffer (that was passed on the recvfrom call). If the

iteration is NOT successful, the client alarm (or timeout) pops – which causes the next

iteration. The client does not retransmit the data. The client terminates after it

completes the desired number of iterations or when a CNT-C is issued. Summary

statistics are displayed that include the mean, max, min of the data set.

To avoid IP fragmentation, the client message size must be less than a network maximum

transmission size (MTU). On an Ethernet or WiFi link, the MTU about 1500 bytes.

Therefore, a message size of 1472 will ensure all of the message fits in a single frame.

As an example of IP fragmentation, consider a message size of 10000 bytes. This

produces an IP datagram of 10028 bytes (10000 application data but 28 bytes of overhead

from IP and UDP). This datagram is broken up into 7 IP packets (which are also called IP

fragments). The IP layer at the server Host is responsible for reassembling the IP

datagram. If all IP packets arrive, the server side IP layer passes the 10028 byte IP

datagram to the UDP layer, which then transfers the 10000 bytes of data from the

datagram into the server application buffer and unblocks the application process (which

was blocked on the recevfrom call).

The server is very simple. It simply loops forever, receiving a packet and then

transmitting the packet back to the sender (i.e., it echoes the received message back to the

server). The server can support any number of clients concurrently. However the server

currently does not correctly handle statistics when multiple clients are active. As an

example, the server assumes packet loss occurs when the next packet that arrives contains

a sequence number that is one larger than the sequence number of the previous message.

If there is more than one client active at the same time, this method for detecting packet

loss will not work.

This homework question involves two separate functional changes to the current

UDPEcho program. First, you are to modify the server so that it maintains a set of

statistics for each client session that it handles. Second, you are to add a new mode of

operation to the client and server.

14

Part 1. Functional Enhancements

Part 1.1 You are to extend the server so that it tracks maintaining statistics on a per

session basis.

Let’s define a ‘session’ as a unique combination of client IP address and client port

number. Note that the client code includes the ability to detect an error and restart the

session. This would cause a new client port number to be used. For this assignment, we

can assume that if this does occur, the server would treat the session as a new session.

The client code does not change for Part 1.1 of this problem. All changes are in the

server. The server code will maintain a data structure that contains a list of session status.

Each session status should contain the following elements:

Client IP : The client’s IPV4 IP address

Client port: The client’s port

Creation time: The time that the session is created

Session mode : A value 0 is echo mode which is what the original UDPEcho

program supports. A value of 1 is the new operating mode (CBR mode, see Part

1.2 of this problem)

Time last message received : Timestamp of last message of the session.

Total number of messages received:

Total bytes received

Most recent sequence number

Count of packets out of order

Count of packets dropped

When the server terminates, it should print a summary of each session in a file called

serverResults.dat. Please use one line per session. Each summary line should include

Client IP

Client port

Duration of session

Total number of messages received

Count of packets out of order

Count of packets dropped

Estimate of packet loss rate

Throughput (bits per second)

The value of the debugFlag parameter determines if the client and server are to log

samples in a log file (RTT.dat and EchoServer.dat respectively).

Client : For mode 0, the client should behave as it currently does- creating the

RTT.dat file if the 8’th bit of the debugFlag is set. For the CBR mode, the client

does not need to create the RTT.dat (in fact, since there are no ACKs, it would

not make sense).

15

Server: For mode 0, the server should create the EchoServer.dat file as done in

the original code. The fprintf should be modified to include the client’s IP and

port (in the first and second fields respectively). The following illustrates an entry

in the correct format:

192.168.1. 15 36281 505946379.680893 1 1000 1 1 0

For CBR mode, the server does NOT need to record the arrival of each message in

EchoServer.dat.

Part 1.2 You are to add a new operating mode to the tool which we call Constant Bit Rate

(CBR) mode

In this mode, the client sends fixed size messages (specified by a parameter) at a constant

packet rate, approximating a constant bit rate (CBR) traffic generator. The server does

NOT send anything back.

The client program adds a parameter called mode. The parameters are:

• Server IPv4 address as a domain name or in dotted quad format

• Server port : specifies the server port

• Iteration delay: Number of microseconds between samples

• Message size: specifies the number of application bytes to place in each message.

In order to ensure a message fits in one IP packet, you should assume a message size can

not exceed 1472 bytes.

• Number iterations: specifies the number of iterations (i.e., data samples) to

perform (or obtain). In CBR mode, you can chose to ignore this parameter or you can

support it by translating it from ‘number of iterations’ to ‘number of packets sent’ before

the client exits.

• Debug flag - See the previous explanation

Mode : a value of 0 for Echo mode, a value for 1 for CBR mode. Assume the

parameter is an unsigned 16 bit integer.

Target sending rate: This the rate (in bits per second) at which the client sends

application data over the socket. This parameter should be an unsigned integer.

In CBR mode, the Message size and the Target sending parameters rate determine the

frequency at which packets are sent. Specifically, the delay time between sequential

client transmissions is:

Tdelay= (M*8)/R seconds where M: message size; R: Target sending rate

The client adds the following fields to each message:

Sequence number (32 bit unsigned int) (the original code did this so)

Mode : 16 bit unsigned int

In mode 0, when the client terminates, it should display the statistics as described above.

In CBR mode, the client should display the duration of the session, the number of

packets sent and the actual sending rate (bits per second).

16

The server learns the client session mode through the mode field in the messages. Note

that the server must support multiple clients that might be in either mode. The server

maintains the session statistics as described in the previous section. At program

termination, the server prints the session summary information in the output file

serverResults.dat as previously described.

Part 2. Validation

You are to conduct an analysis to prove that both added functions to the program works

correctly. You should identify a set of test cases that thoroughly tests your design and

implementation. Your analysis should include the use of tcpdump or wireshark. I am

leaving the details of this up to you. Your writeup should fully document your design

and implementation. It should also document the test cases and results.

Grading: 30 points

Part 1 – 10 points for correctly incorporating session support into the server.

Part 2 - 10 points (full credit) for

Adding the parameters to the client

Adding the mode to the message

Adding a block of code at the client and server for the new mode (does not need

to be completely correct)

Validation and writeup : 10 points divided up as follows:

5 points for two or more test cases for Part 1

5 points for any sort of writeup that documents the design/implementation

Documents

Section 1 (40 points) Short Answer Questions1 CPSC 3600 section 002 HW #1 Solutions Fall 2017 Last revision: 9/29/2017 You must work on this homework individually !! Section 1 (40