Some minor bugs

Question

Hi,

I've found a few minor issues with Integral FTP. I have fixes for two:

* FTPClient_onTransferProgress removes tags from ftpClient._tags via _getTag, so a null tag is passed on subsequent calls to onTransferProgress and onUploadFile/onDownloadFile.
* FTPClient_onDirectoryList passes file.name instead of file.path to fileList.add, so the file name and path have the same value.

You can download the patch from http://www.alittletooquiet.net/media/integralftp/ftpclient-fixes.diff.

The last issue I'm seeing is in the JAR itself, so I can't track it down completely. It seems that after the first file transfer, calls to onTransferProgress continue to be passed the taskID and path from the first transfer. I have a simple example that demonstrates the problem:

http://www.alittletooquiet.net/media/integralftp/integral_ftp_test.zip

To run the test, extract the zip file, copy in the IntegralFTP.jar and ftpclient.js files, edit test.html to fill in the right server information, and open the file in a web browser.

The output I get is as follows:

Initializing...
Initialized.
Connecting.
Connected.
Uploading 1.dat.
Transfer progress: taskID = 2, path = /1.dat.
Uploaded 1.dat.
Uploading 2.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 2.dat.
Uploading 3.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 3.dat.
Uploading 4.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 4.dat.
Uploading 5.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 5.dat.
Uploading 6.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 6.dat.
Uploading 7.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 7.dat.
Uploading 8.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 8.dat.
Uploading 9.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 9.dat.
Uploading 10.dat.
Transfer progress: taskID = 2, path = 1.dat.
Uploaded 10.dat.
No more files.

Is there any way to fix this? Tracking transfer progress correctly with multiple uploads is impossible without a fix.

Thanks,
Forest

Answer 1

My colleague and I have done a bit more analysis of your log and our code.

This is what we think is happening:

1. the server times out a connection (note: previously you would not have noticed this because no exception was logged if a connection in the connection-pool timed out)
2. noticing that a connection has failed, the client tries to reconnect immediately
3. the server, having decided just a moment ago that the client is a connection-hog, disallows the immediate reconnection (note: this is pure speculation to explain the failure of authentication on reconnect)
4. when the client is unable to reconnect it kills all connections

We have made a change so that immediate reconnections are only attempted if less than the minimum number of connections is alive. This should improve robustness. Since the default minimum pool-size is 1, the client will remain connected if there's a connection available.

I've uploaded a new distribution for you which is available at the same URL that I gave you last time.

- Hans (EnterpriseDT)

Answer 2

Hi Hans,

It sounds like your change will be helpful.

The SFTP server is a custom implementation (using paramiko). Credentials are temporary and can only be used once. A new password is generated each time the page is refreshed. This is why reconnection attempts fail. I am using maxPoolSize = 1.

Sorry, I should have mentioned this peculiarity of my setup. The authentication failures are expected. The lost connection is the issue I need to address.

I've posted new client and server logs here:

http://www.alittletooquiet.net/media/in ... 1-03-18-1/

Not sure if that is helpful at this point.

I will test your latest changes right away.

Thanks,
Forest

Answer 3

The disconnects are still occurring.

Answer 4

We believe this is a server error. The server appears to be failing to reply to the keep-alive messages (i.e. SSH_MSG_IGNORE) being sent by the client. The client waits for the reply and when it fails to come before the read timeout it closes the connection and then tries to reconnect. We will add a method to turn off keep-alive. I'll let you know when it's ready for you to download.

Also, have you noticed that Paramiko hasn't been updated since July 2008? It may have been orphaned. If that's the case then I would advise against using it. SSH is a highly complex protocol so code implementing it is necessarily also very complex and error-prone. In my opinion, you therefore really need someone maintaining it constantly.

- Hans (EnterpriseDT)

Answer 5

There's a new distribution available for you at the same URL as before. It includes a new setKeepAliveEnabled method, which you can use to disable keep-alives, which should stop SSH_MSG_IGNOREs being sent, which should stop the read timeouts, which should stop the disconnections. As before, please send a log if it doesn't work as hoped.

- Hans (EnterpriseDT)

Answer 6

Hi Hans,

Sorry, I got busy with some other things and didn't realize you had replied.

I will test the new build as soon as I can and let you know how things go. Thanks for the quick turn around.

-Forest

Answer 7

Hi Hans,

Thanks for your help with this. Unfortunately, I'm still seeing the disconnects, even with the keep-alive feature turned off. They occur after exactly 60 seconds of inactivity.

I decided to test against an OpenSSH server and I see exactly the same behavior there. It doesn't matter if the server is on localhost or if it is on the Internet. The disconnect always occurs after 60 seconds, regardless of whether the IntegralFTP keep-alive feature is enabled or disabled.

I did not see this behavior using the trial version of IntegralFTP that I originally downloaded from the site. Something definitely changed.

Thoughts?

Thanks,
Forest

Answer 8

I can only conclude that the keep-alive thread is still running for some reason. I need to do some testing to confirm this. We're unbelievably busy at the moment. How urgent is this problem? Can you wait a week or so for a patch?

Actually, if you could post or e-mail a log again then I can test my theory.

- Hans (EnterpriseDT)

Answer 9

Hi Hans,

It can wait a week, but not much more than that. I'm also happy to help debug.

What response does Integral FTP expect from the server in reply to SSH_MSG_IGNORE? I've checked the source code of both OpenSSH and paramiko, and they both seem to simply ignore the message without sending a reply. If the client doesn't get a reply, would it disconnect?

Thanks,
Forest

Answer 10

I believe we've identified the problem. I must admit that I'm surprised and embarrassed that I didn't know this until now, but it turns out that the server has not sent a message to the client for 60 seconds then the client connection will disconnect. Normally these disconnections go by unnoticed because the client will automatically reconnect, but it's very noticeable in your case since the reconnections always fail (due to the single-use password policy).

There are two possible solutions to this problem: (1) change the client code such that it doesn't need to read a message every 60 seconds, or (2) send a dummy message every 30 seconds or so and thus force the server to respond. We've discussed these internally and have decided to go with the latter solution. The reasons are that (1) implementing the former runs a high risk of either causing locks or breaking timeout behaviour, (2) sending a message every 30 seconds is useful since it will allow the client to detect connection problems.

We will implement a fix in the next couple of days and let you know as soon as it's ready.

I'm very sorry for the long time you've had to wait for this problem to be resolved, but I'm quite confident that we've diagnosed it correctly now and therefore that we can fix it.

- Hans (EnterpriseDT)