Opened 5 years ago
Closed 5 years ago
#3875 closed enhancement (fixed)
Setup a meeting name server
| Reported by: | Tom Goddard | Owned by: | Tom Goddard |
|---|---|---|---|
| Priority: | moderate | Milestone: | |
| Component: | VR | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Notify when closed: | Platform: | all | |
| Project: | ChimeraX |
Description
When joining a VR meeting one specifies the host address of the machine that started the meeting, e.g. 188.23.133.19 or vive.cgl.ucsf.edu. When using a proxy server for the meeting, for instance, an AWS virtual machine it will typically be the host IP numeric form. This is tedious and error-prone for participants to transcribe into the ChimeraX command "meet 188.23.133.19". It would be nicer of the host of the meeting gave it a name, "meeting start name corona" and then participants join with that name "meet corona". This could be done by having a web service that keeps a mapping of meeting names to host IP (and port). The meeting start command would add an entry and for joining participants, the meeting command would look up entries using this web service.
Change History (4)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
The cgi script should lock the database when adding, deleting or querying so that simultaneous operations do not corrupt it.
comment:3 by , 5 years ago
Would be nice not to implement a custom server. I looked at memcached which is a simple key/value store accessed by TCP/UDP primarily intended for caching database queries. It has python clients, the lightest weight one memcache_client. But a key problem is memcached has no security mechanisms and the main use obtains security by having it only accessible on localhost. As it is mostly used to cache database info which could be sensitive it may be a target for scanning software. An attacker could easily save so many keys that memcached hits its memory limit and it can change any existing keys.
A custom implemented solution could be quite simple and much more tamper proof. The protocol would not be known except to someone reading ChimeraX code. It could allow setting just one key per IP address. It can offer no way to reveal the existing keys. I suspect it would not be abused. It could use a TCP socket, pure Python using the socket module, and just in memory which I think eliminates locking problems since all connections can be handled in a single thread, probably less than 200 lines of code.
I should get a domain chimeraxmeeting.net from sonic and setup the server on an AWS virtual machine for testing.
comment:4 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Done.
Used a simple custom Python name server to have desired security characteristics. Running it on an AWS virtual machine and got domain name chimeraxmeeting.net from sonic.net and use Sonic DNS service to point to the AWS virtual machine. ChimeraX meeting uses this as the default name server. The AWS machine is a free for 12 months t2.micro that I also use as a proxy for ssh tunnels. After 12 months we will need another solution, either hosted at UCSF or a cloud server that will cost money.
One weakness of the current name server is that if someone starts a meeting and loses network connection and quits ChimeraX then the meeting name will not be removed from the server and starting another meeting with that name will say it is in use. I added a meeting unname command to remove the name. Might be better if the name expired after 24 hours.
Ideally ChimeraX would use a default name service that would be maintained for many years. It could be an cloud virtual machine with a domain name like chimeraxmeeting.net.
In order to avoid mischief where people join meetings they are not invited to I could have the web service not provide and list of current meeting names. Further steps could be taken where the meeting host can specify a password that would have to be entered when joining the meeting -- but I'd like to avoid that if possible.
The meeting web service could be a simple Python CGI script. It could support 3 operations, add, query, delete. I need to avoid two meetings choosing the same name, so it should not be possible to replace a current name. But what if ChimeraX crashes or otherwise fails to delete the name when the host closes the meeting? Probably would be good to expire the name after say 12 hours. Might also be nice to allow the same host IP to reuse the name that they already created.