WebRTC revisions and updates including the addition of secure connections. - #1429
Conversation
|
The following links are available: build (ubuntu-18.04, full)
build (macOS-10.15, client) build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
| this)); | ||
|
|
||
| auto dsDirPath = PathUtils::getAppLocalDataPath(); | ||
| const QString KEY_FILENAME = "cert.key"; |
There was a problem hiding this comment.
Constant should probably be on top.
Also it would be nice to have a more unique name than "cert.key". How about "vircadia-webrtc-cert.key"?
There was a problem hiding this comment.
Same comment re constant locations.
Regarding the file name...
The cert isn't necessarily just for WebRTC: it could also be used to secure the server settings page as HTTPS.
The cert is for the DNS domain name being used as the address to connect to the domain server at sop could, in theory, be used for other things also. This might change if we switch to using IP address certs or some other SSL method. Perhaps vircadia-cert.key might be suitable.
See also: #1432
There was a problem hiding this comment.
My thought re: the cert name: I'd like something unique because I found myself trying to figure out where's a given cert for a given program a few times, and there are cases where you may end up with multiple certs in the same directory. It's just nice to clearly know what a cert is for at a glance.
But yeah, vircadia-cert.key works for me.
There was a problem hiding this comment.
I just realized one issue... It's entirely possible that multiple domains on the same server may use a different cert. We should probably keep that in mind now as that will most certainly become a thing.
|
The following links are available: build (macOS-10.15, client) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (self-hosted_debian-11_aarch64, full)
build (windows-latest, full) |
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
|
For some reason it looks like 1429 solves high CPU usage bug. Can someone else build interface from this PR so we can connect to the server and see if audio and avatar mixers work? |
|
I tested it with Kalila. It indeed solves CPU usage bug. |
|
Note that this PR is against the |
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
|
The connection works now, but it's possible to crash server using web-sdk. To cause crash, you need at least two users logged in. Then one user opens multiple tabs and connects, mutes and unmutes each one a few times and closes them without disconnecting. It causes server to crash. |
|
The domain-server.exe crash happens 15 - 30s after closing or reloading the browser tab with the SDK example app connected to the domain server - if the WebRTC connection isn't explicitly disconnected. The following SDK example app PR prevents the crash but doesn't fix the underlying problem: vircadia/vircadia-web-sdk#61 |
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
|
I just built and tested it on Linux and I can confirm. Crashes are gone now. |
digisomni
left a comment
There was a problem hiding this comment.
Using a Windows 10 Interface + Chrome and testing against both the dev-1 (Windows 10) and dev-2 (Ubuntu 18.04) test servers, I couldn't get crashing to happen. Maybe there was one or two oddities with the example not connecting on the first try but otherwise it seems stable.
In order to use the microphone a web app needs to be served as HTTPS. And an HTTPS page requires WebSocket connections be WSS.
Works in conjunction with SDK PR: vircadia/vircadia-web-sdk#50
Cert names are now: vircadia-cert.key, etc.