Details
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)
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
Attachments
Attachments
Issue Links
- is blocked by
-
NET-161 TFTP TFTPClient.sendFile() just doesen't work
- Closed