[ http://issues.apache.org/jira/browse/NET-68?page=comments#action_12436885 ] Jennifer Hodgdon commented on NET-68: -------------------------------------
Neither the 1.41 release version of TFTPClient.java, nor the current nightly build version (as of Sept 15 2006) is working, actually. This bug is still happening. I will attach a zip file (which I just mistakenly put into Bugzilla, sorry!) with some test code. The nightly build version is definitely doing what the bug report stated: dropping the last ACK. When TFTPClient sends a file, it sends a data packet and waits for an ACK, but after the last data packet, it doesn't pick up the last ACK, and then when TFTPClient goes to send/receive another file from the same server, the first thing it gets is the last ACK from the previous send, and it reports an "unexpected packet received" and fails. The version from the 1.41 release doesn't work either -- I can't recall exactly what is wrong with it, actually, but I tested it and it does not work. The version I will attach does work. It would probably be a good idea to use something like this in the next release. I'll also attach my test code: a TFTPClientApp and TFTPServerApp that can be run on two different computers to test the workings of the TFTPClient class. > [net] TFTPClient's send file discards last ack > ---------------------------------------------- > > Key: NET-68 > URL: http://issues.apache.org/jira/browse/NET-68 > Project: Commons Net > Issue Type: Bug > Affects Versions: 1.3 Final > Environment: Operating System: Linux > Platform: PC > Reporter: Perttu Auramo > Fix For: 2.0, 1.5 > > Attachments: patch > > > 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
