[net] TFTPClient's send file discards last ack

• Key: NET-68
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Perttu Auramo
• Affects Version/s: 1.3
• Fix Version/s: 2.0, 1.5

Environment

Operating System: Linux
Platform: PC

Description

TFTPClient reads all acks just fine except the last-one when sending a file. I
figured this out when I tried to use the same TFTPClient-instance for something
else (reading a file) after sending a file. This ack was next in the buffer and
some exception was thrown (don't remember which anymore).

I fixed this for myself using a flag (lastAckWait). Here is a the result of
diff-command:

diff -u TFTPClient.java.original TFTPClient.java.patched
— TFTPClient.java.original 2004-12-28 15:02:37.235997984 +0200
+++ TFTPClient.java.patched 2004-12-28 15:09:14.516602152 +0200
@@ -372,6 +372,7 @@

dataLength = lastBlock = hostPort = bytesRead = 0;
block = 0;
+ boolean lastAckWait = false;

if (mode == TFTP.ASCII_MODE)
input = new ToNetASCIIInputStream(input);
@@ -455,7 +456,10 @@
if (lastBlock == block)

{ ++block; - break _receivePacket; + if (lastAckWait) + break _sendPacket; + else + break _receivePacket; }

else

{ @@ -501,9 +505,8 @@ data.setData(_sendBuffer, 4, offset - 4); sent = data; }

• while (dataLength == 0);
  + while (dataLength == 0 || lastAckWait);

• bufferedSend(sent);
  endBufferedOps();
  }

By the way we have implemented a TFTP server also (heavily unit-tested). I could
try to contribute it back if it fits in commons net. There was some talk in the
web-pages of doing only client-side stuff for commons-net.

-Perttu