Thread: [JSch-users] Poor VNC performance over reverse tunnel
Status: Alpha
Brought to you by:
ymnk
From: B. S. S. <sc...@sm...> - 2011-05-19 17:43:00
|
Hi ymnk, If I use JSch to open a reverse tunnel (session.setPortForwardingR) to a Windows VNC server, when I connect the VNC client to the forwarded port, the performance is very choppy. The same setup with a normal forward (session.setPortForwardingL) performs fine. When I use the OpenSSH command line client to setup the same reverse tunnel (ssh -R5900:localhost:5900 ...), the performance is also very good. After investigating this issue, I discovered that the performance was good with the native SSH client because it was allocating a pseudo terminal (pty) to display the remote command shell. When I instructed the SSH client NOT to allocate a pty (ssh -N -R5900:localhost:5900 ...), I was able to duplicate the same poor performance I saw with JSch. Apparently, if there is no pty assigned to the remote session, the SSH server will buffer and "chunk" the data over all reverse forwards on that session. To test this theory, I hacked up my application with the following code prior to setting up the reverse forward: Channel hackChannel = session.openChannel( "shell" ); hackChannel.setInputStream( new ByteArrayInputStream( new byte[ 100 ] ) ); hackChannel.setOutputStream( System.out ); hackChannel.connect( ); Thread.sleep( 2000 ); hackChannel.disconnect( ); Lo and behold, my VNC performance was then excellent. Obviously, this is not an acceptable solution for my application. I am wondering if you have any ideas on a cleaner, more permanent solution. Do you know if there is a way I can programmatically instruct the SSH server to disable buffering over these channels? I appreciate any input you would have on this issue. Thanks. - Scott Smith |
From: <ym...@jc...> - 2011-05-20 03:15:40
|
Hi, Thank you for your interesting feedback, +-From: "B. Scott Smith" <sc...@sm...> -- |_Date: Thu, 19 May 2011 12:12:18 -0500 ___________ | |After investigating this issue, I discovered that the performance was |good with the native SSH client because it was allocating a pseudo |terminal (pty) to display the remote command shell. When I instructed |the SSH client NOT to allocate a pty (ssh -N -R5900:localhost:5900 ...), |I was able to duplicate the same poor performance I saw with JSch. |Apparently, if there is no pty assigned to the remote session, the SSH |server will buffer and "chunk" the data over all reverse forwards on |that session. Is it needed to keep running pty during remote port forwarding session or is it enough to establish and disconnect pty before requesting port forwarding? If the later is enough, how about ChannelExec#setPty(true) with simple remote command? Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Skype callto://jcraft/ Twitter: http://twitter.com/ymnk Facebook: http://facebook.com/aymnk |
From: B. S. S. <sc...@sm...> - 2011-06-01 18:41:46
|
Hi, Yes, your suggestion also works, just as my hack did, by forcing the allocation of a pty. Unfortunately, I am concerned of the performance and resource ramifications in my application, as there could be hundreds, or potentially thousands of these sessions. Based on your suggestion, I added the following code: // HACK! This is to cause the SSHD not to buffer data for better performance com.jcraft.jsch.ChannelExec hackChannel = ( com.jcraft.jsch.ChannelExec ) dataSession.getSession( ).openChannel( "exec" ); hackChannel.setPty( true ); // Assign a Pseudo TTY to our Session to improve latency for small packets from SSHD hackChannel.connect( ); hackChannel.disconnect( ); After this code executes, any reverse forwards over this Session are high performance (no latency). I am also worried about a timing issue by disconnecting the ChannelExec immediately after connecting in a high-volume scenario. What do you think? Thanks, - Scott On 5/19/2011 10:15 PM, Atsuhiko Yamanaka wrote: > Hi, > > Thank you for your interesting feedback, > > +-From: "B. Scott Smith"<sc...@sm...> -- > |_Date: Thu, 19 May 2011 12:12:18 -0500 ___________ > | > |After investigating this issue, I discovered that the performance was > |good with the native SSH client because it was allocating a pseudo > |terminal (pty) to display the remote command shell. When I instructed > |the SSH client NOT to allocate a pty (ssh -N -R5900:localhost:5900 ...), > |I was able to duplicate the same poor performance I saw with JSch. > |Apparently, if there is no pty assigned to the remote session, the SSH > |server will buffer and "chunk" the data over all reverse forwards on > |that session. > > Is it needed to keep running pty during remote port forwarding session or > is it enough to establish and disconnect pty before requesting port forwarding? > If the later is enough, how about > ChannelExec#setPty(true) > with simple remote command? > > > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > +1-415-578-3454 > Skype callto://jcraft/ > Twitter: http://twitter.com/ymnk > Facebook: http://facebook.com/aymnk |
From: <ym...@jc...> - 2011-06-07 02:22:59
|
Hi, +-From: "B. Scott Smith" <sc...@sm...> -- |_Date: Wed, 01 Jun 2011 13:41:38 -0500 ___________ ... |Based on your suggestion, I added the following code: | // HACK! This is to cause the SSHD not to buffer data for better |performance | com.jcraft.jsch.ChannelExec hackChannel = ( |com.jcraft.jsch.ChannelExec ) dataSession.getSession( ).openChannel( |"exec" ); | hackChannel.setPty( true ); // Assign a Pseudo TTY to our Session |to improve latency for small packets from SSHD | hackChannel.connect( ); | hackChannel.disconnect( ); |After this code executes, any reverse forwards over this Session are |high performance (no latency). |I am also worried about a timing issue by disconnecting the ChannelExec |immediately after connecting in a high-volume scenario. |What do you think? This is an off-topic thing, but is that hack also effective for the local port forwarding, or is there no poor VNC performance phenomena over local port forwarding? Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Skype callto://jcraft/ Twitter: http://twitter.com/ymnk Facebook: http://facebook.com/aymnk |
From: B. S. S. <sc...@sm...> - 2011-06-07 02:25:22
|
Hi, There is no poor performance for local port forwarding, only for remote forwarding. - Scott On 6/6/2011 9:22 PM, Atsuhiko Yamanaka wrote: > This is an off-topic thing, but is that hack also effective for > the local port forwarding, or is there no poor VNC performance phenomena over > local port forwarding? |
From: <ym...@jc...> - 2011-06-06 08:16:48
|
Hi, +-From: "B. Scott Smith" <sc...@sm...> -- |_Date: Wed, 01 Jun 2011 13:41:38 -0500 ___________ | |Based on your suggestion, I added the following code: | // HACK! This is to cause the SSHD not to buffer data for better |performance | com.jcraft.jsch.ChannelExec hackChannel = ( |com.jcraft.jsch.ChannelExec ) dataSession.getSession( ).openChannel( |"exec" ); | hackChannel.setPty( true ); // Assign a Pseudo TTY to our Session |to improve latency for small packets from SSHD | hackChannel.connect( ); | hackChannel.disconnect( ); |After this code executes, any reverse forwards over this Session are |high performance (no latency). |I am also worried about a timing issue by disconnecting the ChannelExec |immediately after connecting in a high-volume scenario. |What do you think? I have no suggestion about timing of disconnection, but in a high-volume scenario, "hackChannel.connect()" may fail(or throw an exception) due to timeout by network latency, out-of-resouces on the remote, etc., so such a case should be cared for. Sicnerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Skype callto://jcraft/ Twitter: http://twitter.com/ymnk Facebook: http://facebook.com/aymnk |