mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Winchester <kevin.winches...@anywaregroup.com>
Subject Re: SSHD: Listeners for Channels?
Date Mon, 01 Oct 2012 14:36:56 GMT


On 01/10/2012 11:32 AM, Guillaume Nodet wrote:
>
>
> On Mon, Oct 1, 2012 at 4:12 PM, Kevin Winchester
> <kevin.winchester@anywaregroup.com
> <mailto:kevin.winchester@anywaregroup.com>> 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:kevin.winches...@anywaregroup.com>> 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


Mime
View raw message