mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: SSHD: Listeners for Channels?
Date Mon, 01 Oct 2012 12:53:10 GMT
On Mon, Oct 1, 2012 at 2:08 PM, Kevin Winchester <
kevin.winchester@anywaregroup.com> wrote:

> Hi,
> I am using SSH local port forwarding in my application, and I would like
> to add some redundancy.  For example, right now I forward local port 80
> through an SSH server, ssh1.example.com, to a target
> server1.example.com:80.  Now, if server1.example.com goes down, I would
> like to forward to server2.example.com instead.
> I am using SSHD for the client and server portions of the connection.
> At the moment, I am using a ForwardingFilter on ssh1.example.com to
> reject forwarding requests if the target server is not reachable. However,
> there does not seem to be any way for my application to find out from the
> SSHD client that the channel failed to open.

The sshd client should receive an SSH_OPEN_CONNECT_FAILED error code with
the exception message, but it has no way to forward to the tcpip client,
because there's no protocol, so the only way is to close the connection.

> Is there a way for me to find this out with the current client
> implementation?  If not, I am willing to implement this capability myself
> and contribute it back to the project.  I was thinking of adding a
> ChannelListener interface that gets called by the session at various points
> in the channel lifecycle (channelRegistered, channelUnregistered,
> channelOpened, etc.).  Does this seem like a reasonable design?  If not,
> does anyone have any recommendations for how this functionality could be
> achieved?

I think the way to handle that depends if the knowledge of the possible
destinations are to be on the client or the server side.
If you can do that on the server side, the client could just specify a port
on the server (ssh1.example.com:8001) and you could easily create a pure
nio proxy using mina which would forward the requests to either
server1.example.com or server2.example.com).
Another alternative on the server side would be  override the
ChannelForwardedTcpip class to provide an alternative one that could try to
connect to the second server if the connection to the first failed.  That
may require a small enhancement in ChannelForwardedTcpip to allow easier
override of the needed code though.

On the client side, the key point to intercept those failures would be
TcpipForwardSupport#sessionCreated().  I suppose this class could also be
enhanced to be more easily extensible.

I don't have any problems with adding a new ChannelListener interface, but
I'm not sure it would be sufficient, as you'd still have to recreate a new
forwarded channel (which should be doable) and to associate this channel
with the incoming socket io session (which seems more difficult).

> Thanks,
> Kevin

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message