CSS 432 - FAQ on Program 2: Sliding Window

CSS 432
FAQ on Program 2: Sliding Window

Q1: Can I run Case 1 without making it hung?

When running the First Case on the Server Side, it always just hangs and never completes. You mentioned on the assignment sheet that the test may hang, but I haven't been able to run it without it hanging. I tried running it the last couple days. Is normal or am I doing something possibly wrong?

A: There are no quarantees to complete Case 1.

If you didn't see that Case 1 was completed in success, that's okay. Don't worry about it too much.

Q2: How can I prevent my program from blocked?

When the window is full, and the client starts the 1500 usec timer, calls read(), and there is no acknowledgement to read, won't my program "hang" while executing read() because there is nothing to read?

A: Use UdpSocket::pollRecvFrom( ).

You have to check if the client's socket has data to read. Otherwise, your client proram will be blocked until data is available. Since UDP does not guarantee every single packet's delivery, once your client is blocked, it may not be resumed. Call pollRecvFrom( ) before reading the socket.

Q3: Strangely my Stop and Wait reports 19962 as the last message recieved but exits normally.

A: Stop and Waits should complete successfully.

One thing you have to be careful of is:

Whenever you receive an ack from the server, please check if its sequence number corresponds to the one you sent to the server. If so, you can increment the sequence number and send a new packet to the server. Otherwise, keep receiving a new ack until the timer is expired. If expired, resend the same packe to the server.

If you don't check the sequence number in the ack upon receiving it, you may end up with sending many packets. This is because an ack may be lost so that another ack with a larger sequence number will be coming and you won't notice this ack loss or packet losss until the very end.

Q4: Does close() prevent recvFrom() from blocking?

A: No.

Q5: Anyone know what kind of ballpark retransmit numbers should we be expecting for these runs?

A: Here are the numbers I got from my experients: 8366 ~ 12974

However, this of course depends on each situtation. Luckily, you may have 0 retransmission, but unluckily, you may have 19,999 retransmissions. However, if you receive abour 20,000 retransmissions no matter how many you repeat your performance evaluation, you may consider my previous advise:

Whenever you receive an ack from the server, please check if its sequence number corresponds to the one you sent to the server. If so, you can increment the sequence number and send a new packet to the server. Otherwise, keep receiving a new ack until the timer is expired. If expired, resend the same packe to the server.

If you don't check the sequence number in the ack upon receiving it, you may end up with sending many packets. This is because an ack may be lost so that another ack with a larger sequence number will be coming and you won't notice this ack loss or packet losss until the very end.

Q6: When we turn in our source code in tomorrow for program 2, did u want us to only turn in the hw2.cpp file? Or did you want all the other files also printed out?

A: Turn in only your udp.cpp file.

If you have modified the other files such as hw2.cpp, UdpSocket.h, UdpSocket.cpp, Timer.h, and Timer.cpp, turn in all those modified files, too.

Q7: Does the window size start from 0 or 1?

A: My hw2.cpp assumes that the window should have at least one packet to send.

Q8: How can the server program keep track of which packets have been delivered to it?

A: Prepare an array whose index corresponds to each packet's sequence number.

While the strict sliding window algorithm must allocate such an array whose size is the same as a given window size, you may allocate an array whose size is 20,000, in which case each array index corresponds to a different packt's sequence number. This simplifies your server program. Whenever the server program has received a new packet, simply mark the corresponding array element, so that you can find which packet the server program is expecting to receive.

Q9: Where is gnuplot?

A:/usr/bin/gnuplot

If you want to know how to use it, type "man gnuplot". Also, visit http://www.gnuplot.info

Q10: Is test case 2 supposed to take a really long time?

Elasped time = 30368842
retransmits = 0
These are the numbers I got over a 1Gbps connection.

A: This is too slow. There must be some logic errors.

Look at page 22 of p2p.ppt. It shows my HW2's performance results. Approimately, 100Mpbs needs 8,000,000usec (=8secs) and 1Gbps needs 3,000,000usec (=3secs). Your case is really slow. Please double-check your code or visit my office.