Feature: allow the use of TURN to connect client and server together #9447
Conversation
|
After fiddling with several solution for the "people should know their session is being relayed" part, I settled on the following solution: When you join a server, and the session turns out to be relayed, you are being told about this via an info-popup. In this popup is the address of the relay service. For our binaries that will read I did thinker a bit with adding a "You are about to connect to |
TrueBrain
force-pushed
the
turn-around
branch
2 times, most recently
from
dfdba7e to
87a3ff7
Compare
Minor issue with this approach .. I can only show the warning when it happens, but if you are joining, all warnings are removed just before you enter the game .. so you see this popup for a short moment for it to vanish into thin air. Also, it is a fucking nag screen .. I need a better approach for this :D Maybe only show it once per TURN server, and ask to "accept" the relay server. Edit: what nags me a bit about this, if someone wants to do bad, he can create his own client, host his own GC and TURN, force TURN on every connection, and remove what-ever-we-add-to-tell-the-user. So maybe this is just all complete non-sense anyway, and it is just bikeshedding. Maybe something like this works: I guess we need something like this. |
|
Out of curiosity, why is it so important to inform the user that they are being relayed through an official OpenTTD server? Simply a privacy disclosure, or something else? |
|
Exactly that. The user might expect that the connection between them and the server is private, but without any indication or notification is can now be relayed through our infra. I am just not sure if and how to make the user a participant in this story .. it is tricky to do without being very technical about it :) |
|
This is what I came up with:
It feels smooth and looks to be working well. So I think we have to go for this for now. |
|
On popular request, increased the time you see the above red window from ~8 seconds to ~18 seconds. Hopefully that solves the "I didn't have time to read the window" comments I have gotten :) No clue what a good value is, as to me 8 seconds already sounded like a long time. But it is now even longer! :D |
TURN is a last resort, used only if all other methods failed. TURN is a relay approach to connect client and server together, where openttd.org (by default) is the middleman. It is very unlikely either the client or server cannot connect to the STUN server, as they are both already connected to the Game Coordinator. But in the odd case it does fail, estabilishing the connection fails without any further possibility to recover.
Note: this is currently only deployed on staging. To test it out:
OTTD_COORDINATOR_CS="coordinator.openttd.org:4976" OTTD_STUN_CS="localhost" ./openttdMotivation / Problem
As final piece of #9017, this introduces TURN support in the OpenTTD client. This is meant to allow connecting those clients and servers that we cannot connect in any other way.
With this, it should be possible in nearly all situations for player A to play with player B, without any configuration in their network. The situations where it won't be possible are most properly extremes: those who do not have (stable) Internet, or those that have very poor peering and cannot connect to our TURN servers.
Description
For OpenTTD TURN is expensive, as we are paying for the relaying (bandwidth cost), and as such the Game Coordinator does its at-most to find any other means first.
Additional, our TURN-servers are not off-the-shelves TURN-servers, but instead they validate the protocol they are relaying. This avoids us being used as TURN-server for any other purpose other than relaying OpenTTD.
Future work extends TURN-servers to allow Websockets, meaning we can provide full network support for our Emscripten builds. But this is kept out of this PR for now.
Limitations
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.