HOMEWORK 2 FAQ Last Revision: 500 PM, Feb 20, 2004 ERRATA ------ Problem 2a: Should read: "What is the probability that there will be ATLEAST 1 collision before ...." Problem 2b: Should read: "What is the probability that one station successfully transmits a frame after exactly 2 collisions?" Problem 2c: Should read: "What is the probability that one station successfully transmits a frame after exactly k collisions?" Problem 2d: Should refer to Part c, NOT Part a. Problem 6b: "Suppose A wins the second backoff race. Then it will transmit A2. A and B collide again when A tries to transmit A3 and B tries once more to transmit B1." Problem 6c: ... We want the probability that A wins collision rounds 4, 5, 6, ... , infinity. Problem 7c: Assume there are N nodes. Problem 8: M should be the number of sequence numbers; i.e., {0, 1, ... , M-1}. Problem 9: o You can assume an infinite sequence number set (at least as big as u_char will hold). o The three test runs should be: (1) W=W'=1; (2) W=4, W'=1; (3) W=W'=4. [ Note: I changed test run 2. ] QUESTIONS/ANSWERS ----------------- Problem 1 --------- Problem 2 --------- Problem 3 --------- Problem 4 --------- Problem 5 --------- Q5-1) Is the slot time in Part a suppose to be 51.2 usec or 512 bit times? A5-1) No. It is defined to be "the time required to detect a worst-case collision". In this problem, it is the worst-case 2-way propagation delay. This is not Ethernet (although it looks like Ethernet in some ways). It is 1-persistent CSMA/CD. Q5-2) I noticed that in your lecture notes you have something like: Slot Time = 2 x (Max round-trip propagation time) This looks wrong. Shouldn't it just be: Slot Time = 2 x (Max 1-way propagation time) = (Max round-trip propagation time) A5-2) Yes, the notes are wrong. Problem 6 --------- Q6-1) In Part c, it seems that A can win forever and therefore, the probability will be 1. Is that what this question is asking? A6-1) A may win forever, but the probability that it can do that is NOT 1. Part a asks for Pr[A wins round 2]. Part b asks for Pr[A wins round 3]. If you had an expression for Pr[A wins round n], Part c is asking for Pr[A wins all rounds in 4, 5, 6, etc.]. This probability is a joint probability and therefore a product of values that are less than 1. Q6-2) In 6b, I was wondering if the lower bound would be atleast 0.5 since A would only have 2 options 0 or T. A6-2) There are an infinite number of lower bounds - some better (tighter) than others. 0.5 is an obvious lower bound ... as you argue above. With a little work, you should be able to get a tighter lower bound. Problem 7 --------- Q7-1) You also ask for an upper bound on TRT in Part c. Do you mean the TRT for a network in part b or any network? If either case, I can see the upper bound is infinity because THT can be arbitrary. A7-1) In part c, assume N nodes. The TRT will be finite. What part c is asking is what is the minimum TTRT given N nodes each with identical THTs. So, TRT = f(N, THT, Rotational latency). Problem 8 --------- Q8-1) It seems that M in part a. means the maximum sequence number, but in part b, it seems that M means the number of sequence number. Which meaning of M should we follow ? A8-1) Sorry about that. Let's assume that M is the number of sequence numbers. But if you have already done the problem using the other definition, then just leave it alone if you don't have time to change it. Problem 9 --------- Q9-1) Are we suppose to use select() to do asynchronous I/O so that we can respond immediately to returning ACKs? A9-1) For this assignment, you don't need to do that. In fact, you don't want to do that for now. We'll do that on the next assignment. For now, your sender logic should look like: while (there are frames to send) { if (sender window is not full) { Buffer next frame F; Send F; } else { Wait for ACK; Slide window 1 frame; } } Note that since we are creating pseudo-frames, you could just create a single frame skeleton and just update those parts of that frame that you need. Q9-2) How do I tell the receiver that the sender is done? A9-2) The easiest thing is to send an extra frame marked as EOT (End-Of-Transmission) when the sender is done. Q9-3) What are the sndr and rcvr fields in the frame header? And why are they 6 characters? A9-3) Put in some fake MAC address that is easy to recognize as faulty if transmitted improperly. What is important is that the receiver needs to swap the sndr and rcvr fields in the header before transmitting the ACK. Here are a couple you can use: hdr_t hdr; for (int i=0; i<6; i++) { hdr.sndr[i] = i+1; hdr.rcvr[i] = 27-i; } Q9-4) Is there a recommended approach to doing this so as to reduce my chances of falling into a deep hole? A9-4) Here is one possibility that I think lends itself to rapid development: 1) Create and send 2 frames to a receiver that just prints out some meaningful message that the frames arrived properly. Run both on the same host so that it is immune to byte ordering and you can set the server host name to 'localhost'. Maybe add in rudimentary hex output code that you will improve later to help you locate coding problems. 2) Extend the code to do Stop-and-Wait WITHOUT using the SndWinBuf and RcvWinBuf classes. Again run the sndr and rcvr on the same host. 3) Extend the code to the case W=4, W'=1 and use SndWinBuf or its equivalent. 4) Extend to the case W=4, W'=4 and use RcvWinBuf or its equivalent. 5) Handle byte ordering and test on heterogeneous host architectures. Q9-5) How can we use infinite sequence numbers if the sequence number field in the header is of type u_char? A9-5) That field can hold atmost the sequence number 255. For testing purposes, you can assume that is infinity (i.e., you will never use a larger sequence number). Q9-6) TCP_NODELAY and IPPROTO_TCP do not seem to be defined. A9-6) On my Linux host, TCP_NODELAY is defined in (i.e., /usr/include/netinet/tcp.h) which you could have found by entering: grep TCP_NODELAY /usr/include/*.h grep TCP_NODELAY /usr/include/*/*.h Look in for IPPROTO_TCP. Q9-7) For the receiver (server) do you want us to ack every packet, no matter the window size, as soon as it is received? The provided class seems only to provide functionality for that (in fact, for our current project, I don't honestly see how it does anything useful). A9-7) To be precise, since we know that there are no errors, you don't need to do anything. But we'll pretend that pkts can get lost. So, ACK every pkt for now. Q9-8) I've read on the web that u_char is not strictly defined to be 8 bits and that if size matters we should use u_int8 instead. A9-8) Do you mean u_int8_t??? Or uint8_t??? Well, if you use u_int8_t, Linux will recognize it but not Solaris since ISO C recognizes uint8_t. Probably uint8_t is the way to go since that is the ISO C definition. Q9-9) What should I put in the frame body? A9-9) Whatever you want, but it would be nice to put something that you could read easily and verify is correct. This is what I did: sprintf(&(frame.body[0]), "%3d", frame.hdr.seqNum); frame.body[3] = '='; for (int j=4; jnxtSn(), wherever seq. num is required? A9-13) That seems reasonable. Also, you will need to indicate to the receiver that the transmission is complete. So, you may need an extra sequence number or header flag or something. nxtSn() should give you what you want, but you should look at the implementation of nxtSn() so that it is clear that that is what you want to do. Q9-14) And what should be the logic in the receiver? Recv. 1 frame, ACK 1 frame ( untill EOT) ? or Recv. W' frames and ACK W' frames in 1 shot ? A9-14) Either one. It really doesn't matter much in this assignment since nothing is dropped. The next assignment will make it important. Q9-15) I think I might have a weird bug in this seemingly simple code for sender and receiver. When I run my program a number of times, with different nframes, in very few cases my sndr apparently sends all nframes (including EOT) to rcvr and terminates, but sndr does not seem to receive all packets and still tries to send ACK to sndr which has terminated and I get a broken pipe error. A9-15) Note that if you put your sndr and rcvr in verbose mode, you should see messages that tell you what is going on. To make it easier to see and correlate the output, you can put an artificial delay of say 1 or 2 sec (e.g., sleep(2)) before ACKing in rcvr and you will see the interaction in real-time. The classic way the sndr should be operating is that once it has sent out all of its frames (and only the Nframes) that it tells the rcvr it is done (usually a special frame) and then continues looping but only looking for ACKs. It should not quit until it sees the proper last ACK. Note that this FIN phase is straightforward in this assignment because no ACKs get dropped ... lucky you.