On Mon, Oct 1, 2012 at 9:53 AM, Guillaume Nodet wrote:
On Mon, Oct 1, 2012 at 2:08 PM, Kevin Winchester <
[email protected]> wrote:
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).
It would be the client side that has the knowledge of the destinations,
so I took a look at TcpipForwardSupport#sessionCreated() as you
suggested. I agree that creating an alternate implementation of that
class would likely work to accomplish my goals. If I were to attempt
that, how would you want the ClientSessionImpl changed to be able to
accept an alternate TcpipForwardSupport implementation?
Alternatively, with the ChannelListener interface, my plan was to
completely tear down the port forwarding tunnel and recreate it:
clientSession.startLocalPortForwarding(new
SshdSocketAddress("localhost", 80 ), new
SshdSocketAddress("server1.example.com", 80));
<Add channel listener to the session, and if the channel fails to open:>
clientSession.stopLocalPortForwarding(new SshdSocketAddress("localhost",
80));
clientSession.startLocalPortForwarding(new
SshdSocketAddress("localhost", 80 ), new
SshdSocketAddress("server2.example.com", 80));
Would that work?
Thanks for your help,
Kevin
