In the TFTP protocol: If the client changes its port number on a subsequent conn
ID: 3730506 • Letter: I
Question
In the TFTP protocol:
If the client changes its port number on a subsequent connection, but the server does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?
If the server changes its port number on a subsequent connection, but the client does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?
2. In an RPC-like protocol in which multiple requests can be outstanding, and replies can be sent in any order: Assume that requests are numbered and that ACK[N] acknowledges reply[N]. Should ACKs be cumulative? If not, what should happen if an ACK is lost?
Explanation / Answer
In the TFTP protocol:
If the client changes its port number on a subsequent connection, but the server does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?
If the server changes its port number on a subsequent connection, but the client does not, what prevents an old-duplicate data packet sent by the server from being accepted by the new client?
ANS ==>
Trivial File Transport Protocol is an actual protocol based on UDP, we consider the Trivial File Transport Protocol, TFTP. While TFTP supports clients sending files to the server, we will restrict attention to the more common case where the client requests a file from the server.
TFTP shouldn't be used when the connection is not near-perfect (=local, few hops). UDP isn't reliable by itself and TFTP doesn't do enough to improve on that very much.
In the above, the server changes to a new port s_port when answering. While this change plays a modest role in the reliability of the protocol, below, it also makes the implementer’s life much easier. When the server creates the new port, it is assured that the only packets that will arrive at that port are those related to the original client request; other client requests will be associated with other server ports. The server can create a new process for this new port, and that process will be concerned with only a single transfer even if multiple parallel transfers are taking place.
However, the example is somewhat hypothetical. Both client and server are likely to use ephemeral ports chosen by the OS. The time window for the duplicate packet to match is very small - the queue flush time of a router in between - and the ephemeral port numbers would need to wrap around on both sides simultaneously.
That said, TFTP should only be used on short connections where security doesn't matter - if at all. There are more modern alternatives for reliable and secure file transfer.
-----------------------------------------------------------------------------------------------------------------------------
2. In an RPC-like protocol in which multiple requests can be outstanding, and replies can be sent in any order: Assume that requests are numbered and that ACK[N] acknowledges reply[N]. Should ACKs be cumulative? If not, what should happen if an ACK is lost?
ANS==>
To determine which reply matches which request it is necessary to number the requests and replies . reply can serve to acknowledge the request; if reply[N] is not received; the requester retransmits request[N]. This can happen either if request[N] never arrived, or if it was reply[N] that got lost
When the server creates reply[N] and sends it to the client, it must also keep a cached copy of the reply, until such time as ACK[N] is received hence it is possible to ACKs Be Cumulative but after sending reply[N], the server may receive ACK[N], indicating all is well, or may receive request[N] again, indicating that reply[N] was lost, or may experience a timeout, indicating that either reply[N] or ACK[N] was lost. In the latter two cases, the server should retransmit reply[N] and wait again for ACK[N]