If you want to be fully asynchronous, you need to use listeners.
sshClient.connect( host, port ).addListener(
new SshFutureListener<ConnectFuture> {
public void operationComplete( ConnectFuture connect ) {
ClientSession session = connect.getSession();
// start authentication process ...
}
});
On Fri, Sep 28, 2012 at 2:02 PM, Kevin Winchester <
kevin.winches...@anywaregroup.com> wrote:
> On Thu, Sep 27, 2012 at 8:44 PM, Kevin Winchester <
>> kevin.winches...@anywaregroup.**com <kevin.winches...@anywaregroup.com>>
>> wrote:
>>
>> Hi,
>>>
>>> I see that TCP/IP forwarding has been added to the SSHD client in the
>>> upcoming 0.8.0 release. I have grabbed the latest code from SVN to try
>>> it
>>> out, but I have a few questions:
>>>
>>> 1. Is there any sample code for how to use it? I basically am doing the
>>> following:
>>>
>>> SshClient sshClient = SshClient.setUpDefaultClient()****;
>>>
>>> sshClient.start();
>>> ClientSession clientSession = sshClient.connect( host, port
>>> ).await().getSession();
>>> clientSession.authPassword( username, password ).await();
>>> clientSession.****startLocalPortForwarding( new SshdSocketAddress(
>>>
>>> localAddress, localPort ), new SshdSocketAddress( remoteAddress,
>>> remotePort
>>> ) );
>>>
>>> I don't want any shell or execution channel, just the port forwarding. Is
>>> that the best way to make use of the feature?
>>>
>>>
>> Yes
>>
>
> Great, thanks. I plan to make more use of the asynchronous nature of the
> API in the future. Would I be able to call connect(), authPassword() and
> startLocalPortForwarding() without calling await() on any of the Futures
> first?
>
> Hmm. Looking at the code, it looks like I cannot get a valid ClientSession
> from the ConnectFuture until the connection is complete, so I guess I would
> not be able to call authPassword() without first waiting. I don't see the
> same dependencies between authPassword() and startLocalPortForwarding()
> though. Should I be able to call those in sequence, or should I call
> await() on the AuthFuture first?
>
>
>
>>
>>
>>> 2. When I run the above code, the channel seems to work correctly, until
>>> I
>>> disconnect for the first time, at which point the channel seems to close
>>> itself. Is that something I am doing wrong, or is it the intended
>>> behavior? Any other SSH client I have used maintains the forwarded
>>> channel
>>> across multiple disconnects/reconnects.
>>>
>>>
>> I've just added a loop to the unit test we have and the current code seems
>> to support multiple socket opening/close correctly.
>> See testLocalForwardingNative in
>> https://github.com/apache/**mina-sshd/blob/trunk/sshd-**
>> core/src/test/java/org/apache/**sshd/PortForwardingTest.java#**L189<https://github.com/apache/mina-sshd/blob/trunk/sshd-core/src/test/java/org/apache/sshd/PortForwardingTest.java#L189>
>> Channels are created for each incoming socket connection on the remote
>> side.
>> Are you saying that the channel is kept opened for a certain amount of
>> time
>> before being closed if not reused ?
>> I suppose I can see the use case for example when using HTTP 1.0, but I
>> must admit that did not crossed my mind.
>> Feel free to raise a JIRA issue and eventually propose a patch if you're
>> fancy working on it.
>>
>>
> I just tried again this morning and I saw exactly what you describe - new
> channels were created for each connection to the forwarded port. I'm not
> sure what was going on yesterday, but I'll continue my testing. If I see
> the disconnection again, I'll grab the logs from server and client (both
> are SSHD) and post them here.
>
>
>
>> 3. I see that there is a createDirectTcpipChannel method in the
>>> ClientSession class as well, that seems to create a completely different
>>> implementation of a forwarded TCP/IP channel. What is that used for?
>>>
>>>
>> The main difference is that the startLocalPortForwarding opens a server
>> socket and will channel incoming connection through the ssh layer.
>> The createDirectTcpipChannel serves a slightly different purpose which is
>> to stream data from java to the remote host, so no socket is opened and
>> you
>> have to give the input / output / error streams instead.
>> The reason the implementation is different is mainly because in
>> the startLocalPortForwarding case, no java streams are used, and we use
>> bio
>> buffers, so even if ssh layer is used in the same way, the client side is
>> slightly different.
>>
>>
> Good to know - thanks. The reason I asked is that the
> startLocalPortForwarding method does not return any reference to the
> channel. The reason I wanted to get the channel is that I was wondering if
> there is a way to add a listener for channel events. Or alternatively, I
> would love to be able to monitor the socket that gets opened for port
> forwarding to know when it is ready/in use/closed. Is there any support
> for those kinds of things? If not, would you be willing to accept them if
> I managed to get them added to the code?
>
> Thanks again for the quick responses. The more I look into the
> well-organized code from this project, and the more I see your willingness
> to help out users, the happier I am getting about choosing SSHD for my
> project.
>
> Kevin
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
