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 Tue, 02 Oct 2012 12:47:29 GMT
Hi,

I have completed the changes you outlined below adding the 
TcpipForwarder interface and factory.  How would you like me to 
contribute them? Create a JIRA issue for them and attach the patch? 
Email the patch here (attached or inline)?

Thanks,
Kevin


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.
>
>
>     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

Mime
View raw message