This test has five questions; answer at least four of them. The test runs one hour, and ends at 5:30.
Up to the first 75 words appearing after a question are taken to be the answer to the question. Words following the 75th word are not part of the answer and will be ignored.
Using compression to improve latency will almost certainly not work. Compressed application PDUs are shorter than uncompressed PDUs, which may improve delay because the last bit may be received earlier, but compression has no effect on latency, which is the time it takes to get the first bit.
The one possibility in favor of compression occurs if your colleague’s application becomes so popular that it takes up some huge percentage of total network bandwidth. Compressing application PDUs in this case may reduce network load, enabling lower latencies.
Assuming a point-to-point, client-server connection, the connect() method is
used only by the client to make the connection to the server, and the
listen() method is used only by the server to accept (or not) the client’s
connection request. Once the connection has been established, either the
client or the server can use the remaining read(), write(), and
close() methods.
Answer one: If TCP2 omits the first packet in a three-way handshake (the initial packet from sender to receiver), then the sender has no way of contacting the receiver to make the connection, and TCP2 is clearly broken.
Answer two: If TCP2 omits the second packet in a three-way handshake (the packet from receiver to sender), then both sides of the connection are unable to establish common state to implement the connection, and TCP2 becomes the equivalent of UDP, which doesn’t work as well as TCP.
Answer three: If TCP2 omits the third packet (the second packet from sender to receiver) the answer is either a) then the sender can ack the receiver’s sequence number in the first packet it sends to the receiver, in which case TCP2 is works as well as TCP, or b) unacknowledged receiver sequence numbers can lead to obscure conditions in which TCP2 deadlocks in the presence of long-lived packets, in which case TCP2 doesn’t work as well as TCP (which should be clear because otherwise TCP would use a two-way handshake).Application A cannot replace IP with UDP. IP doesn’t support ports, which means that A must be communicating with a host rather than a process on a host. UDP supports ports, which means (in general) it communicates with process on a host and can’t communicate with the host itself (because the host doesn’t have a port number).
Application B cannot replace UDP with IP for the reverse reason given in the previous answer. B must be communicating with a process on a host, and IP has no way of addressing that process.
This question can also be answered with respect to checksums. IP checksums the header only, while UDP checksums the header and payload (and a few other things). Replacing a checksum over a header with a checksum over a packet (that is, replacing IP with UDP) is fine, but replacing a checksum over a packet with a checksum over a header (that is, replacing UDP with IP) leaves the payload unprotected.A UDP-based application gets no incidental reliability by implementing slow start for congestion control. Slow start doesn’t use timeouts and retransmissions, so there’s no recovery on packet loss. With no retransmissions, slow start doesn’t cause duplicate packets, but it also does nothing prevent or recover from duplicates. Slow start has nothing to do with either packet order or corruption, so there are no gains there.