Opened 5 years ago
Last modified 5 years ago
#4515 assigned defect
Creating meeting timed out making tunnel to server
Reported by: | Tom Goddard | Owned by: | Tom Goddard |
---|---|---|---|
Priority: | moderate | Milestone: | |
Component: | VR | Version: | |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Notify when closed: | rkimera@rhsp.org | Platform: | all |
Project: | ChimeraX |
Description
Ssh command to make tunnel to server when starting meeting timed out after 5 seconds for meeting started in Mali to Uganda server setup by Rodgers Kimera.
Begin forwarded message:
From: Rodgers Kimera
Subject: RE: ChimeraX meeting feature issues with ACE Mali.
Date: April 14, 2021 at 6:27:33 AM PDT
To: Tom Goddard
Dear Tom,
Our error is different from the one you highlighted. It more looks at connection timing out.
<screenshot of error attached>
The same command succeeds when here in Uganda and fail for Mali.
I expected the 2 commands
meeting access acemali address 137.63.184.167 account tunnel key C:/Users/Public/tunnel-key.pem
meeting start testmeeting access acemali
to create a meeting called “testmeeting” for others to join.
Kindly advise.
Thank you.
Regards,
Rodgers
Attachments (1)
Change History (3)
by , 5 years ago
Attachment: | image003.png added |
---|
comment:1 by , 5 years ago
comment:2 by , 5 years ago
The meeting command does not have a good way to handle ssh timeouts. The meeting command uses a 5 second default timeout and when starting a meeting it hangs ChimeraX for the full 5 seconds because the ssh command subprocess has no way to tell ChimeraX that the tunnel has been established. Using a longer timeout, say 30 seconds, means ChimeraX will be hung for 30 seconds. If no timeout is specified I think ssh uses the default socket connection timeout of 70 seconds. Slow or unreliable meeting startup is a pretty big problem. Four ideas for solving it are all bad. There is an ssh -f option that causes ssh to background itself once the tunnel is made. This works by forking another process with the original ssh process exiting. This almost solves the problem except that ChimeraX then has no way to kill the ssh tunnel since its Popen instance exits and no process id is available for the backgrounded ssh. A second idea is to try to connect to the tunnel a few times a second until a connection succeeds. This has various problems -- like the port may be already in use so the tunnel fails but the query connection succeeds. A third solution is to use a Python ssh module (asyncssh) to make the tunnels which gives more detailed info about tunnel status. This could lead to ugly problems with Python handling threads very poorly. A fourth solution is to abandon ssh and write some server program that maybe uses port 443 (https / ssl). That is obviously a lot of work and leaves ChimeraX handling authentication and encryption instead of letting ssh do all that work it is well designed for.
Begin forwarded message:
From: Tom Goddard
Subject: Re: ChimeraX meeting feature issues with ACE Mali.
Date: April 14, 2021 at 9:54:26 AM PDT
To: Rodgers Kimera
Hi Rodgers,
The first thing to try is to use a longer timeout when connecting to the server. This can be specified when you name the server with the meeting access command
The "timeout 30" option will allow 30 seconds to connect when you start the meeting. If this works it will unfortunately take 30 seconds to start the meeting even if the connection is made faster. The ssh command does not give any indication that the connection was established so ChimeraX will wait the full 30 seconds before trying to use the connection and ChimeraX will just be frozen for those 30 seconds. That is why I have the default timeout set to 5 seconds.