You need to raise a JIRA issue, attach your patch and make sure you grant the copyright to the ASF with the corresponding checkbox.
On Tue, Oct 2, 2012 at 2:47 PM, Kevin Winchester < [email protected]> wrote: > 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 <[email protected]> >> <mailto:kevin.winchester@**anywaregroup.com<[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: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 >> <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.__e**xample.com <http://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.__e**xample.com <http://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 >> > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
