- Host A connects to host B using TCP to perform an HTTP request. Host B closes the connection once it has provided a response. Request size is 500 bytes and response size is 3000 bytes. The initial sequence number on A is 1000 and the initial sequence number on B is 5000. MSS for both hosts is 1460 bytes. Please detail the sequence of TCP segments exchanged from the beginning till the end of the connection (for each segment list: sender, sequence number, acknowledgement sequence number, active flags and number of data bytes) under the following conditions:
- No flow control, no congestion control. Regular acknowledgements.
No flow control means you are free to assume that receiver is always happy to receive new data, so it is ok to assume recv_window >= 1 MSS anytime.
No congestion control means that your sending is not restricted by any value of the congestion windows, that you can assume anytime cong_win == infinite.
Initial sequence numbers are increased by one due to the SYN segment exchange at the beginning, so first data byte from A will be 1001 (and 5001 from B).
Request from A can be sent in a single segment with sequence number 1001 (containing 500 data bytes) that will be acknowledged with number 1501. Response from B has to be splitted into three segments of sizes 1460, 1460 and 80 data bytes each.
But the three segments can be transmitted without waiting for any delay (remember, no flow or congestion control). Each one of these segments will carry value 1501 for the acknowledgement number.
Connection will be closed by B, so this is started by sending a FIN segment, with sequence number
- Same as before but using delayed acknowledgements.
- Same as (2) but using congestion control. What is the congestion window size on each end when FIN is received?
- Write a simple UDP echo server. (No need to create a class or method, just the main server loop).
DatagramSocket ds = new DatagramSocket(7777);
//Port of the server is not mentioned, so we use the one we want
Datagram packet dp = new DatagramPacket(new byte[1024],1024);
// these lines above are not needed in a valid answer.
while(true) {
ds.receive(dp); // received datagram packet over socket
ds.send(dp); // send it back to the source
}
- During a TCP connection, one end receives a segment with recv_window = 0. What does it mean? What does this end do if there is application data to be transmitted?
Broadly speaking it means that we no longer can transmit more data (flow-control in action) until a new received segment reports a larger-than-zero value. Retransmissions are possible though.
However, if you look at the RFC 793, page 41: The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero. The sending TCP must regularly retransmit to the receiving TCP even when the window is zero. Two minutes is recommended for the retransmission interval when the window is zero. This retransmission is essential to guarantee that when either TCP has a zero window the re-opening of the window will be reliably reported to the other.
Therefore, if more application data is pending, this sender will wait till it can be transmitted (but it will send 1 byte segments every now and then). No error condition is signal to the application (as this condition is perfectly normal).
- Assuming all TCP segments transmitted are acknowledged right away, what is the value of the congestion window after sending 35 segments after a Timeout if Threshold = 3
