Is there an sftp session time limit ?

Question

We have a situation where we occasionally have to catch up with uploads that have not been sent. What seems to be happening is that the sftp session just stops with no errors after 60 minutes (its using modems !). The server looks fine. It uses BeginPutFile, and in tests I have sent (say) 3 files successfully but the one that is in progress during the 60min mark just stops being transmitted, with nothing calling the callback and no exceptions thrown. Is there something that can be set up to effect the session length (or something) that might cause this ?

Comments

Does this occur with the special updated legacy .NET CF 1.0 build of Rebex SFTP - v2.0.3484.9?

Some servers might (and do) impose a time limit, but this should only apply to inactive sessions. We definitely don't impose any limit on our own. However, if it happens consistently after 60 minutes, it might be related to SSH's session re-negotiation. Please let me know which version of Rebex SFTP you use, we will look into this.

---

Yes Lukas, it is with 2.0.3484.9 - we are very happy so far, and trying to close down our beta, but have found this single issue (as described - when there are a large number of uncompressed files to upload after some time without being able to connect).

I initially thought this was due to one of our timeouts misfiring, as we have one at 60minutes, but I have repeatedly tested through that one several times now and am confident it is not the culprit. I can find no session timeouts or limits on the (globalscape) server.

---

Thanks for clarification, we'll look into this! I will let you know if we need any additional information.

Answer 1

We found a bug in the legacy .NET CF 1.0 build of Rebex SFTP (v2.0.3484.9). It was in the Monitor.TryEnter replacement routine (which is only present in this version and not in any other build) that made it impossible for a single thread to enter twice. This occurred when SSH session re-negotiation was requested by the server while a transfer or other command sequence was in progress, blocking the thread.

I sent a link to a patch to your e-mail - please give it a try and let me know whether it helps!

Comments

Thanks Lukas, I'll test that out tomorrow.

What would be your recommendation for the best way to monitor the engine status during a session ? I am now monitoring : - the transfer progress event with a 3min no-activity timeout, - the state changed event, but this doesnt fire in this situation.

---

What about monitoring whether the transfer progress event actually keeps firing? I mean - 1. when the event fires, set a "last transfer progress" field to the current time, 2. have a timer check the field every few minutes, 3. if the field has not been updated for N minutes, raise an "transfer has stuck" event.

---

First big test with updated ssh looks good - 90mins of transfer and normal close :) It made me worried at the 60min mark when the progress event got delayed by 10s though ;) Thanks very much for a very fast response.

---

I've decided to put in a record of the last time either event arrives and time out if that exceeds 3mins. Testing has shown that the dispose hangs with this bug though, so that means the watchdog will end up restarting the box, but at least we've got better monitoring in case of anything similar now.

---

The 10s delat at 60min mark was the session renegotiation - no data packets can be transferred while it's in progress. Good to hear it works! :-)

---

Regarding Dispose that hangs up - it looks like this is a bug. Dispose method is missing in SshSession and Sftp's Dispose simply calls SshSession.Close, which is NOT a Dispose and tries to close the connection gracefully. Thanks for letting us know, we'll definitely fix this as well! Update: This has been fixed in release 2013 R1.