Check the connection/tunnel with SSH Client

Question

Hi,

I have been using the SSH forwarding tunnel API from the SSH total pack beta build for a few days now and have a question. Is there a way to check wether you are still connected (sudden internet connection failure on the other side) and even better: are the tunnels still set to forwarding. I have disabled TCPkeepalive on the server side, because the clients are on a crappy 3G connection and they tend to loose connection without telling the server. The client then has a reconnect timeout and logs back in after a certain amount of time, but the port-forwarding have to be released by then, so the client can request them again. I have noticed that it can occur that the client is logged in, but the server does not forward the ports. The re-login timeout is however longer than the tcpkeepalive on the server side so it should rrelease the ports. So my questions are:

1. Is there a way to check wheter the client is still connected and logged in. So KeepAlive with feedback.
2. Is there a way to check wheter the server is still forwarding a certain port?
3. Am I overlooking a dead simple solution?

Kind regards,
Lars van Ruiten

Answer 1

1) Currently, the recommended approach to this is periodically calling the KeepAlive method on the Ssh object's underlying SshSession object (see this answer for an example with Sftp).
2) Not at the moment. However, this looks like a must-have functionality and we will add it eventually.
3) No. It just looks like the current version of the API is too simple for this scenario.

Thanks for your valuable feedback!

Comments

Allright, but I do not think that the following would work:

client.Session.keepAlive();
Thread.Sleep(2000);
if(!client.isConnected) {
    //restart client
}

Suppose that for example someone would pull the ethernet cable from the server just before I send the keepAlive. Will it detect that it is not connected anymore?

---

In this case, the first `KeepAlive` call will not detect that the connection was lost, but it will cause the underlying connection to fail very soon (because no TCP ACK packets are going to be received), causing subsequent `KeepAlive` to fail.