Discussion: How to reliably detect if SftpClient is still connected

[IgorMilavec]

I need to implement SFTP connection pooling. As part of this I need to have long running SftpClients and a way to check if the client is still connected. Initially I used SftpClient.IsConnected for this purpose. However, even if SftpClient.IsConnected returned true, I many times got this exception when trying to use the SftpClient instance:

System.InvalidOperationException: The session is not open.
   at Renci.SshNet.SubsystemSession.EnsureSessionIsOpen()
   at Renci.SshNet.SubsystemSession.SendData(Byte[] data)
   at Renci.SshNet.Sftp.SftpSession.SendMessage(SftpMessage sftpMessage)
   at Renci.SshNet.Sftp.SftpSession.SendRequest(SftpRequest request)
...

Here is the class diagram of the relevant portion of SSH.NET: https://gitmind.com/app/flowchart/75ace876ac90aec4dbce3b61347c6cf9

Based on this architecture, it seems to me that the described problem is caused by SftpClient not taking into account the SubsystemSession's state. As an intermediate workaround I made BaseClient.IsConnected virtual and implemented it in SftpClient as:

        public override bool IsConnected
        {
            get
            {
                return base.IsConnected && _sftpSession.IsOpen;
            }
        }

Initial tests show this solves my problem, but further testing is needed to really claim this.

Can someone with more insight into the codebase confirm my reasoning so far? I would also be thankful if the one could answer the questions that pop up in my mind looking at this class diagram:

• There are a lot of classes named *Session in this diagram... can someone explain what these classes do conceptually? Is the naming good?
• Is there a reason for Session and SubsystemSession to hold their own respective status? Does/should a change in one's state relate to a change in the other's state?
• Why do BaseClient and Session each hold ConnectionInfo? Are these two the same?

[WolfspiritM]

That's interesting. We've been running SFTP for over a year now with pooling connections without ever getting this error (at least not noticing it) but recently since a few days ago without any update on our side we started to see some connections to fail with the "The session is not open" exception, too. We're also using IsConnected to check if the connection is still open.

[IgorMilavec]

This behavior seems to be triggered by specific configuration on the server. I only get this for some partners. I presume these partners have session timeout configured and their server disconnects the SFTP session, but does not terminate the connection.
Are you willing to try the above workaround to see if it works for you?

[avr2222]

I am getting the same error. Any suggestions?

[IgorMilavec]

You could implement the above mentioned workaround. I haven't seen this error since I implemented it.

[avr2222]

You mean implemeting this?
public override bool IsConnected
{
get
{
return base.IsConnected && _sftpSession.IsOpen;
}
}

[IgorMilavec]

I have pushed the required changes to https://github.com/IgorMilavec/SSH.NET/tree/Issue843 so you can do a private build.
No PR to upstream at this time as I feel this needs to be discussed further. @drieseng, any thoughts on this?

[avr2222]

Ok fine. For now, i will try this and update you.

[anandgmenon]

This issue seems to be still relevant, can we open a fix to address this?

[WojciechNagorski]

Yes

[mus65]

The proposed fix is imho not correct or at least not complete. Connect() will throw an exception if the connection is still open. That means the following code would throw an exception if the SFTP session is closed, but the connection is still open.

if (!sftpClient.IsConnected)
{
  sftpClient.Connect();
}

You would obviously not expect this to fail. Not sure what the correct approach/fix would be here, I just thought this was worth mentioning.