Protocol failure on "busy" server

[joeclarkia]

We are using node-tftp as a TFTP server to send a file to an embedded device. Under "normal" conditions the server and needed file transfer work fine. But in some cases (especially if we do something potentially CPU intensive simultaneously on the server, like generating a graph with Plotly), the transfer will fail.

Looking at wireshark, it appears that the following occurs:

• the client (Linux tftp) sends acknowledgments in "lock step"
• at a certain point the server (node-tftp) fails to send the next data segment <-- the anomaly
• After a brief period of time (100ms) the ack is seen again, and the server sends the next segment, and the client sends the appropriate acks, BUT the server appears to not process any acks after the anomaly occurs, and in fact it starts sending a series of segments, always starting with the first one after the anomaly occurred.

Now, as a UDP-based protocol, I understand that dropped packets (for any reason) are to be expected, but as far as I've read, TFTP should gracefully handle the situation, not in effect fail the transfer. Am I missing something?

[joeclarkia]

Example data flow:

• DATA 4540
• ACK 4540
• (time gap, 100ms)
• ACK 4540
• DATA 4541
• ACK 4541
• DATA 4541, 4541, 4542 (basically at the same time)
• ACK 4542
• DATA 4541, 4542, 4541, 4542, 4543 (at same time)
• ACK 4543
• DATA 4541, 4542, 4543, 4541, 4542, 4543, 4544
• .....