Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: allow the use of TURN to connect client and server together #9447

Merged
merged 2 commits into from Jul 20, 2021

Conversation

TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Jul 17, 2021

Note: this is currently only deployed on staging. To test it out:

  • Host your server on a port that you do NOT forward (you do not want to have a Public server).
  • We "disable" STUN by using a server that doesn't exist ("localhost"). This will give a connection error, that is fully expected.
  • Start the game like: OTTD_COORDINATOR_CS="coordinator.openttd.org:4976" OTTD_STUN_CS="localhost" ./openttd
  • Host a server, join as client .. there is a 2 second delay till it switched to TURN. This is because it is expecting STUN, but as we "disabled" that, it will fail. There is a 2 second timeout on waiting for STUN, hence the delay.

Motivation / 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

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.

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.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

docs/game_coordinator.md Outdated Show resolved Hide resolved
src/network/core/tcp_turn.h Outdated Show resolved Hide resolved
@TrueBrain
Copy link
Member Author

TrueBrain commented Jul 18, 2021

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 turn.openttd.org or similar. It also includes a link to a page (which I have yet to create) to explain what is going on, in language non-techies can understand.

I did thinker a bit with adding a "You are about to connect to turn.openttd.org; are you sure?" dialog, but came to the realisation that most people will not understand what it is asking them (and just always click 'yes'). Such windows in general are not all that useful to add.
I think it is more useful to tell people they are being relayed, and on the page it points to explain if they don't want to, they should disconnect from the server. After all, there is no other way we can connect them otherwise, so there is not much difference. But this way we have a small opportunity to educate our users with a bit more room than just one or two sentences as we would have in-game.

@TrueBrain TrueBrain force-pushed the turn-around branch 2 times, most recently from dfdba7e to 87a3ff7 Compare July 18, 2021 21:06
@TrueBrain
Copy link
Member Author

TrueBrain commented Jul 18, 2021

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 turn.openttd.org or similar. It also includes a link to a page (which I have yet to create) to explain what is going on, in language non-techies can understand.

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:

We cannot connect you directly to the server. We would like to relay your session via 'relay.openttd.org'.

<no> <yes, this once> <yes, always>

I guess we need something like this.

@2TallTyler
Copy link
Member

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?

@TrueBrain
Copy link
Member Author

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 :)

@TrueBrain
Copy link
Member Author

This is what I came up with:

image
image

It feels smooth and looks to be working well. So I think we have to go for this for now.

@TrueBrain TrueBrain marked this pull request as ready for review July 19, 2021 19:54
@TrueBrain
Copy link
Member Author

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

src/settings_type.h Outdated Show resolved Hide resolved
src/network/network_gui.cpp Outdated Show resolved Hide resolved
src/network/network_gui.cpp Outdated Show resolved Hide resolved
src/network/network_gui.cpp Outdated Show resolved Hide resolved
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.
@TrueBrain TrueBrain merged commit fa1e279 into OpenTTD:master Jul 20, 2021
@TrueBrain TrueBrain deleted the turn-around branch July 20, 2021 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants