johnsie / HoverNet

An open-source 3D racing game
http://www.hoverrace.co.uk
Other
1 stars 1 forks source link

Online Racing Doesn't Work #3

Open johnsie opened 4 years ago

johnsie commented 4 years ago

HoverRace was written before most people had routers, firewalls and private NATS in their homes. This meant that the same could use any port on the WAN address without having to worry about port forwarding etc. Players connected directly to each other over dial-up.

Now that we all have routers and LANs in our homes we need to find a way to allow the HoverRace clients to communicate with each other. Possible solutions for this include:

geoff-white commented 4 years ago
  • VPN so that all clients are effectively on the same network. This presents some security issues as players may not want to be on the same 'network' as strangers.

The use of split-tunnelling may make the potential VPN solution less insecure, so long as the tunnel is designed for application-specific traffic only.

johnsie commented 4 years ago

Here are some interesting libraries/solutions that may be used:

Miniupnp

Provides a simple solution for udp portforwarding. Downside is that it doesn't work on all networks or with all routers. I have tested this and it works for some people but not others. I can release this as part of the pre-release package this week, but it cannot be the final solution.

Display something somewhere in the client so the user can know if this works for them

RakNEt

https://github.com/facebookarchive/RakNet/tree/master Facebook/Oculus bought this library which supposedly caters for several holepunching techniques, including miniupnp and possibly some other methods. I still need to do some reading about this one, and it looks like it would be a lot of work, but could provide a suitable solution.

Switch to server based solution

HR already has a lot of code for TCP communication, including packet creation and reception. The problem with TCP is that it can be jumpy due to it not ignoring late packets. UPD is recommended because it just ignores late packet. I now think that this should only be used if Raknet fails.

Final product should be:

1.Try racknet

  1. if raknet fails, use server
  2. If server fails tell the user their net config isn't suitable.

Conclusion and dev order

Short Term (Phase 1 Pre-releases): Implement miniunpnp which should at least be usable for some users. Get an idea of what percentage of users it fails for.

Long Term (Phase1): Implement Raknet. And in the

Even Longer Term (Probably Phase 1, although I may let some phase 2 fixes come in prior ): Implement fallback to tcp server in case raknet doesn't work.