For each state below, spell out plausible responses for a TFTP receiver upon receipt of a Data[N] packet. Your answers may depend on N and the packet size. Indicate the events that cause a transition from one state to the next. The TFTP states were proposed in 11.4.2 TFTP States. (a). UNLATCHED (b). ESTABLISHED (c). DALLYING

The TFTP specification is relatively informal; more recent protocols are often described using finite-state terminology. In each allowable state, such a specification spells out the appropriate response to all packets. We can apply this approach to TFTP as well.

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

When the receiver-client first sends RRQ, it does not know the port number from which the sender will send packets. We will call this state UNLATCHED, as the receiver has not latched on to the correct port. In this state, the receiver waits until it receives a packet from the sender that looks like a Data[1] packet; that is, it is from the senders IP address, it has a plausible length, it is a DATA packet, and its block number is 1. When this packet is received, the receiver records s_port, and enters the ESTABLISHED state.

Once in the ESTABLISHED state, the receiver verifies for all packets that the source port number is s_port. If a packet arrives from some other port, the receiver sends back to its source an ERROR packet with Unknown Transfer ID, but continues with the original transfer.

Here is an outline, in java, of what part of the TFTP receiver source code might look like; the code here handles the ESTABLISHED state. Somewhat atypically, the code here times out and retransmits ACK packets if no new data is received in the interval TIMEOUT; generally timeouts are implemented only at the TFTP sender side. Error processing is minimal, though error responses are sent in response to packets from the wrong port as described in the previous section. For most of the other error conditions checked for, there is no defined TFTP response.

The variables state, sendtime, TIMEOUT, thePacket, theAddress, thePort, blocknum and expected_block would need to have been previously declared and initialized; sendtime represents the time the most recent ACK response was sent. Several helper functions, such as getTFTPOpcode() and write_the_data(), would have to be defined. The remote port thePort would be initialized at the time of entry to the ESTABLISHED state; this is the port from which a packet must have been sent if it is to be considered valid. The loop here transitions to the DALLY state when a packet marking the end of the data has been received.

// TFTP code for ESTABLISHED state while (state == ESTABLISHED) { // check elapsed time if (System.currentTimeMillis() > sendtime + TIMEOUT) { retransmit_most_recent_ACK() sendtime = System.currentTimeMillis() // receive the next packet try { s.receive(thePacket); } catch (SocketTimeoutException stoe) { continue; } // try again catch (IOException ioe) { System.exit(1); } // other errors if (thePacket.getAddress() != theAddress) continue; if (thePacket.getPort() != thePort) { send_error_packet(...); // Unknown Transfer ID; see text continue; } if (thePacket.getLength() < TFTP_HDR_SIZE) continue; // TFTP_HDR_SIZE = 4 opcode = thePacket.getData().getTFTPOpcode() blocknum = thePacket.getData().getTFTPBlock() if (opcode != DATA) continue; if (blocknum != expected_block) continue; write_the_data(...); expected_block ++; send_ACK(...); // and save it too for possible retransmission sendtime = System.currentTimeMillis(); datasize = thePacket.getLength() - TFTP_HDR_SIZE; if (datasize < MAX_DATA_SIZE) state = DALLY; // MAX_DATA_SIZE = 512 } 

Note that the check for elapsed time is quite separate from the check for the SocketTimeoutException. It is possible for the receiver to receive a steady stream of wrong packets, so that it never encounters a SocketTimeoutException, and yet no good packet arrives and so the receiver must still arrange (as above) for a timeout and retransmission.