On 01/10/2012 11:32 AM, Guillaume Nodet wrote:
On Mon, Oct 1, 2012 at 4:12 PM, Kevin Winchester
<[email protected]
<mailto:[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
<mailto:[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
<http://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 <http://server1.example.com> or
server2.example.com <http://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.
Ok, I'll try to implement this and see how it would work.
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.
Actually, losing all existing connections doesn't bother me - there
would typically only be one connection at a time through the tunnel and
if the target server stops responding, then that connection would likely
have to be restarted anyway to get to the second server. That said,
since you prefer the first approach, I'll work on that and hopefully get
it working for my needs.
Thanks,
Kevin
