Question

Assume both the TFTP sender and the TFTP receiver implement retransmit-on-timeout but not retransmit-on-duplicate. Outline a specific TFTP scenario in which the TFTP receiver of 16.4.2 TFTP States sets a socket timeout interval but never encounters a “hard” timeout – that is, a SocketTimeoutException – and yet must timeout and retransmit. Hint: arrange so the sender regularly times out and retransmits some packet, at an interval less than the receiver’s SocketTimeoutException time, but it is not the packet the receiver is waiting for

Answer 1

The TFTP specification is comparatively informal; newer protocols are often described using finite-state terminology. In each allowable state, such a specification spells out the suitable response to all or any packets. we will apply this approach to TFTP moreover.

Above we defined a DALLY state, for the receiver only, with a selected response to arriving Data[N] packets. There are two other important conceptual states for TFTP receivers, which we would call unlatched and established.

When the receiver-client first sends RRQ, it doesn't know the port number from which the sender will send packets. we'll call this state unlatched, because the receiver has not “latched on” to the proper port. during this state, the receiver waits until it receives a packet from the sender that appears sort of a Data[1] packet  that, it's from the sender’s IP address, it's a plausible length, it's a packet, and its block number is When the  packet is received, then receiver records the s_port, and after that it enters inthe established  state.

Once it comes in the established state, the receiver has to verify for all the packets that the source port number is s_port. If the  packet arrives from the another port, then the receiver sends back the packet to the  source an Error  packet with “Unknown Transfer ID”, but continues with the first transfer.