PROGRAM B FAQ (FREQUENTLY ASKED QUESTIONS) ------------------------------------------ Last Updated: Mon, 400 pm, Mar. 29, 1999 INDEX ----- Q1) In the sliding window protocol, if my client is carrying out several transmissions sequentially, and the server begins to ack back before the client has finished sending all the packets in the window. It has occured to me that the client will not be listening to the port; then will this ack will be lost in the transaction? Q2) It has occurred to me, that I may want to try to fork a process, to carry out the listening function while the client is in the mode of sending. Q3) Do I pick either "go back n" or "selective repeat" or do I have to do both? Q4) The structures for the sender's buffers seem to be very complicated. Is it some hashing scheme? Q5) I don't see why the receiver in stop-and-wait needs a buffer. Q6) Doesn't the number of buffers have to equal the window size? Q7) Are we supposed to be acknowledging every packet recieved by the server. Because now I am having trouble keeping my client and server in Synch. When we had stop and wait the sequence of events was obvious: (SEND HDR; SEND DATA; RECV ACK). As I understand the process is now (W=#segments): CLIENT_SIDE (do W times {SEND HDR; SEND DATA}; do W times {RECV ACKS}). SERVER_SIDE (do W times {RECV HDR; RECV DATA}) SEND ACKS for those sequence numbers that have been recvd. When is the selective acknowledgement/Go back n going off? And how does the client know when to expect it? Q8) If window =5, and packet 2 is dropped when ack 2 doesn't come back to the client isn't this defacto selective repeat? Q9) How do I keep my server from hanging when I am listening to the port for (window size) number of packets, lets say all of them get dropped, doesn't this mean the server will now be hung? He is expecting window size packets and the xread function will be sitting there until it gets the window size number of packets. Q10) Im confused on how to implement a timer. I can only monitor a timer, or listen to the port. How do you set AND monitor a timer, and listen to the port for packets. Or how do I only listen for x number of seconds. If my client or server makes a call to xread and nothing is there I hang the process and everything stops. Q11) I am not sure I understand how the details of clock timeout is implemented in (A7) using select. Can you be more specific? Q12) From Program A, you probably have an idea of what a good RTT value. We are not trying to estimate RTT in Program B. Just set it to beta*RTT for some suitable beta and RTT estimate (from Program A). Q13) Do you know if there is manual page for select? I am just wondering that if we use select to implement timeout, does this mean the process is doing nothing before select times out? Q14) The only difference between project1 and project2 is that we use sliding window protocol instead of stop-n-wait protocol, and everythings else is the same. Is that true? That is we are supposed to implement the sliding window protocol to transfer files QUESTIONS/ANSWERS ----------------- Q1) In the sliding window protocol, if my client is carrying out several transmissions sequentially, and the server begins to ack back before the client has finished sending all the packets in the window. It has occured to me that the client will not be listening to the port; then will this ack will be lost in the transaction? A1) TCP is running underneath and will buffer everything. Everytime you do a read (or recv) you will get some portion of what has actually been sent. Q2) It has occurred to me, that I may want to try to fork a process, to carry out the listening function while the client is in the mode of sending. A2) Don't do this. Have one process. Because TCP buffers you just do what you did in Program A. But one problem is how to handle timers. But here, you should do what TCP does. Set a timer that goes off every N ms. You should be able to pick a reasonable N from Program A. These define tick points. Then, you timeout by ticks; i.e., all ACK timeouts are in ticks. This same timer can be used to measure the RTT. Q3) Do I pick either "go back n" or "selective repeat" or do I have to do both? A3) It is a command line option, but in the end you need to be able to one or the other within one run. Q4) The structures for the sender's buffers seem to be very complicated. Is it some hashing scheme? A4) In general, it is a list or list of lists. But in this assignment, you know how many buffers there will be after you process the command line arguments. Also, the segment (packet) size is in multiples of 200 bytes. Since we will assume fixed length packets, we will pick a simple solution. You could generalize this later. Let's suppose it is 4 800-byte segments. Then, you can just have a ring buffer arrangement: a 2D character array. char buff[4][800]; int nxtBuf = 0; // next free slot; // nxtBuf==firstBuf ==> all buffers in use int firstBuf = -1; // oldest buffer // firstBuf == -1 ==> no buffers in use This can be improved by using: char *buff; char *nxtBuf; // init to &(buff[0]) char *firstBuf; // init to NULL and dynamically allocating the space. Q5) I don't see why the receiver in stop-and-wait needs a buffer. A5) In our case, you are right because we are simulating a fast receiver. In general, buffers serve two functions: 1) Insulate the user from the details of sending/receiving a packet (e.g., allow the user to proceed while the packet is being delivered; free the user from having to know the details of efficient packet segmentation). 2) Smooth out traffic (i.e., handle bursty traffic). So, in a real system, the protocol implemenation would have to wait for the user to make a call that will copy the data from the internal buffers to user space or the user must have indicated before the segment arrived where the system could copy data directly into user space (i.e., user-space buffers). But we are simulating the fact that the user will take the segment as soon it is available. If not, the receiver must buffer the incoming segments. Similarly, the code on the sender side could buffer incoming packets from the user when the window is full. Q6) Doesn't the number of buffers have to equal the window size? A6) In general, no. See the discussion about smoothing the traffic in Q5/A5. But in our experimental setup, you can assume that the application program at both the sender and client sides are matched to the outgoing/incoming traffic flow. So, the sender blocks when the window is full, and the receiver only needs enough buffers for error control: 0 for stop-and-wait; and the window size minus 1 for selective-repeat. Q7) Are we supposed to be acknowledging every packet recieved by the server. Because now I am having trouble keeping my client and server in Synch. When we had stop and wait the sequence of events was obvious: (SEND HDR; SEND DATA; RECV ACK). As I understand the process is now (W=#segments): CLIENT_SIDE (do W times {SEND HDR; SEND DATA}; do W times {RECV ACKS}). SERVER_SIDE (do W times {RECV HDR; RECV DATA}) SEND ACKS for those sequence numbers that have been recvd. When is the selective acknowledgement/Go back n going off? And how does the client know when to expect it? A7) There are two regions of operation: 1) Build up to the window size; and 2) Maintain the window. I would say: CLIENT_SIDE { do W times {SEND HDR; SEND DATA}; while (not Done) { wait for ACK or clock timeout; // select if clock timeout { ... increment clock ... ... retransmit if necessary ... } else { if (not duplicate ACK) { SEND next segment } else { ... Handle duplicate ACK ... } } } } The server just ACKs every segment. Q8) If window =5, and packet 2 is dropped when ack 2 doesn't come back to the client isn't this defacto selective repeat? A8) No. Go-back-n says that the client should retransmit everything it has sent starting with packet 2. Selective-repeat says just resend packet 2. Q9) How do I keep my server from hanging when I am listening to the port for (window size) number of packets, lets say all of them get dropped, doesn't this mean the server will now be hung? He is expecting window size packets and the xread function will be sitting there until it gets the window size number of packets. A9) You don't wait on W packets. You wait for 1 packet (200 bytes in our case). So, you xread the header; then xread the 200-byte body. Q10) Im confused on how to implement a timer. I can only monitor a timer, or listen to the port. How do you set AND monitor a timer, and listen to the port for packets. Or how do I only listen for x number of seconds. If my client or server makes a call to xread and nothing is there I hang the process and everything stops. A10) You do the same thing you did in Program A. select is waiting for an asynchronous event that includes I/O and a timer set to a clock ticks worth of time. See A7 for the client code. So, the client doesn't do an xread until it knows something is there. The server doesn't care about a timer. So, it is just issuing xreads. Q11) I am not sure I understand how the details of clock timeout is implemented in (A7) using select. Can you be more specific? A11) The semantics of 'select' is that it will return if either an I/O has completed or a timeout has occurred. The user sets the timeout interval to N msec for a suitable N. Everytime select indicates a timeout occurred, you increment a counter that represents a virtual clock. All buffers have a timeout expressed in terms of a virtual clock value. So, you can tell if a buffer transmission timed out. Unfortunately, the minimum timeout value is hardware dependent (timer resolution) and typically is the minimum clock interrupt value (10 ms). What will happen if you write a test program that just timeouts every 10 ms? You will most likely see time difference values varying between 5 ms and 15 ms!!! Q12) Which RTO equation should be use? And do we have to estimate the RTT value? Q12) From Program A, you probably have an idea of what a good RTT value. We are not trying to estimate RTT in Program B. Just set it to beta*RTT for some suitable beta and RTT estimate (from Program A). Q13) Do you know if there is manual page for select? I am just wondering that if we use select to implement timeout, does this mean the process is doing nothing before select times out? A13) Enter "man -s 3c select" on a solaris system. 'select' waits for an I/O event (one with a file descriptor) that you have scheduled to be watched to occur. So, your process goes into a wait state. But the time it stays in the wait state is limited by the timeout indicated in parameter 3. Q14) The only difference between project1 and project2 is that we use sliding window protocol instead of stop-n-wait protocol, and everythings else is the same. Is that true? That is we are supposed to implement the sliding window protocol to transfer files A14) You don't need to do a real file transfer. All you have to do is send the packets - they can contain dummy data.