On Mon, Oct 1, 2012 at 4:12 PM, Kevin Winchester < [email protected]> wrote:
> On Mon, Oct 1, 2012 at 9:53 AM, Guillaume Nodet wrote: > >> On Mon, Oct 1, 2012 at 2:08 PM, Kevin Winchester < >> kevin.winches...@anywaregroup.**com <[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? > I suppose we'd have to add a TcpifForwarder interface (with request / cancel / close methods) and a related factory (with a ClientSession interface as a parameter) and add this factory to the ClientFactoryManager interface ... That's a bit overkill, but it's the cleanest way I think. > > 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 <http://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 <http://server2.example.com>", 80)); > > Would that work? > No, because you'd loose existing socket connections. Stopping the local port forwarding would kill any existing connection, so all sockets would have to be recreated. > > Thanks for your help, > Kevin > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
