Timeout expired, session have not responded

[BlueGI]

Recently we upgraded to version 6.5.8 05-May-15. I cannot recall if we had any previous version issues, but lately we are having trouble uploading files larger than 1 GB. It seems that once it reaches 1020MB (or thereabouts), it stops and waits for the TimeOut period. Then an exception of "Timeout expired, session have not responded" is returned.

It always happens on 1020MB. Other apps, like FileZilla, have no problems uploading to our server.
The amount of time it takes to reach 1020MB varies based on the WriteBlockSize we use, so it is not an issue of how long the connection is kept open.

If we change the TimeOut property to something longer, then the time between when it stops uploading and the time when it returns the message is increased, but nothing else changes.

The Error event handler is not being called, either.

Is there something happening around 1GB that changed? Is there some property we're not setting? Any help would be appreciated.

[ViktorV]

Thank you for the information. We are investigating this behavior of SecureBridge, and we will inform you about the results.

[BlueGI]

Any more news on this? We reverted back to our previous version, 6.3.5, and that one works as expected. Has anyone else experienced this? We made no code changes in our application. Just compiled using the old and new versions of SecureBridge.

[ViktorV]

We continue investigation of the problem and will inform you as soon as we get any results.

[nathschu_sel]

I experienced this doing low-volume transfers (serial port / terminal forwarding with ymodem data).

The codebase used TScSSHShell.Timeout = 0 so that calls to TScSSHShell.ReadBuffer() with 'count' parameter = large like 1024 would return immediately. Also the codebase had TScSSHClient.Timeout = 15 (so you have to think about which class's timeout you're changing).

One thing TScSSHShell.Timeout controls is how long the component waits to receive SSH_MSG_CHANNEL_WINDOW_ADJUST after it has exhausted its available send window. If the timeout is zero, and if the client send window becomes exhausted, the component gives up immediately (throwing that exception you mentioned) without waiting for the server to send a new SSH_MSG_CHANNEL_WINDOW_ADJUST message.

In my case, the SSH server "slowed down" after receiving [x] bytes, which delayed the SSH_MSG_CHANNEL_WINDOW_ADJUST message delivery enough to exhaust the SSH client's send window.

I corrected the problem by using non-zero value for TScSSHShell.Timeout, and never pass a value larger than TScSSHShell.InCount for the 'count' parameter (which is the intended way to achieve non-blocking behavior).

[Dimon]

Recently we upgraded to version 6.5.8 05-May-15. I cannot recall if we had any previous version issues, but lately we are having trouble uploading files larger than 1 GB. It seems that once it reaches 1020MB (or thereabouts), it stops and waits for the TimeOut period. Then an exception of "Timeout expired, session have not responded" is returned.

We have reproduced this problem and fixed it. This fix will be included in the next SecureBridge build.

[Dimon]

I experienced this doing low-volume transfers (serial port / terminal forwarding with ymodem data).
...

We can not reproduce the problem. Please, try to compose a small sample to demonstrate the problem and send it to dmitryg*devart*com.