Make Tracker Changes Transparent To Users

[CDarrow]

Arch's tracker is super cool and all, but it's a hassle to have to explain to the whole community how to switch trackers, which one they have to use when for what reasons, check whether one or the other is down when hosting a game, etc.

It would be nice if Retro could take a list of trackers, and just register with / check all of them for games.

Or if the trackers could tell each other about games (See Icewolf's suggestion for the alt tracker registering with the main -- register under its own IP, respond to game info requests with "Actually, it's at this IP", which we'd have to teach Retro to understand).

Or if we had a tracker tracker list somewhere that we could modify and which Descent cached and used and everything was transparent.

Or something.

[adam2104]

I've been thinking about this as well. I've got the code necessary for sending register packets, however, dealing with the IP mismatch is problematic. I've thought about that too and I think this could potentially be combined with the idea to host without doing port forwarding. Idea:

1. Game registers with tracker.
2. another game queries tracker for games, chooses one of the games that comes back.
3. when the game is selected to join, two things happen:

a. the game sends a game join indicator to the tracker. this causes the tracker to forward the IP/port of the joiner to the original host of the game.

b. the original host of the game starts sending dxx-p2p-ping packets to the potential joiner

c. the potential joiner sends game request packets to the host, creating a bidirectional packet flow which should open most stateful firewalls.

Of course, all this would have to happen over a single UDP socket between the game(s) and the tracker, which it doesn't currently do, for reasons I still don't understand.

[CDarrow]

Not bad! Yeah, we are going to have to collapse that to a single UDP socket to make hosting without port forwarding feasible. That does mean we'll have to deconflict the packet IDs on the two protocols, but that doesn't sound like rocket science to me.

The ideas I've heard for making the tracker switch transparent are:

1. Have Descent take a list of trackers, independently register with each one, and deconflict all the game lists itself. Change Descent's internal default of a single tracker to the existing two. Advantages: Totally transparent to everyone, allows tracker protocols to change by tracker. Disadvantages: Might be a lot of work to do inside Descent.
2. Have the trackers tell each other about games -- coordinate with the Rebirth guys to build a "register game from another tracker" protocol into the main tracker. Advantage: Probably the easiest way to do things, technically. Disadvantage: Still tied to main tracker protocol
3. Have the alt tracker register games with the main under its own IP, and have Descent accept a packet from the game host that says, "Actually, the game is on this new IP...". Advantage: Pretty simple solution. Disadvantage: Puts a significant amount of work on the alt tracker.

I really am leaning toward solution 1. It seems the most powerful and flexible option, even if it is the most work for me personally.

[adam2104]

I have a proof of concept multi-client UDP relay stack working. I'm going to try registering games to the main tracker with my IP and then relay the incoming packets to the original host. Anything from the host to specific clients will be relayed in back to those clients.

I'm not sure what the impact will be to relaying everything but I figured its worth a shot. If for no other reason than to see how well I can register to the main tracker. And it's not a stretch to get from this to option 3.

Adam

On Aug 22, 2014, at 2:01 PM, Catherine Darrow notifications@github.com wrote:

Not bad! Yeah, we are going to have to collapse that to a single UDP socket to make hosting without port forwarding feasible. That does mean we'll have to deconflict the packet IDs on the two protocols, but that doesn't sound like rocket science to me.

The ideas I've heard for making the tracker switch transparent are:

Have Descent take a list of trackers, independently register with each one, and deconflict all the game lists itself. Change Descent's internal default of a single tracker to the existing two. Advantages: Totally transparent to everyone, allows tracker protocols to change by tracker. Disadvantages: Might be a lot of work to do inside Descent.

Have the trackers tell each other about games -- coordinate with the Rebirth guys to build a "register game from another tracker" protocol into the main tracker. Advantage: Probably the easiest way to do things, technically. Disadvantage: Still tied to main tracker protocol

Have the alt tracker register games with the main under its own IP, and have Descent accept a packet from the game host that says, "Actually, the game is on this new IP...". Advantage: Pretty simple solution. Disadvantage: Puts a significant amount of work on the alt tracker.

I really am leaning toward solution 1. It seems the most powerful and flexible option, even if it is the most work for me personally.

— Reply to this email directly or view it on GitHub.

[CDarrow]

Cool! Keep me advised. :)

[vLKp]

CDarrow said:

Yeah, we are going to have to collapse that to a single UDP socket to make hosting without port forwarding feasible. That does mean we'll have to deconflict the packet IDs on the two protocols, but that doesn't sound like rocket science to me.

I do not think that is a problem, for two reasons. First, you only need port forwarding for unsolicited inbound traffic. If the game sends a message to the tracker, the tracker can respond regardless of the game's source port (until the router times out the connection tracking entry, but those often last for a few hours, so even intermittent keep alives to the tracker would preserve that entry). Second, even if you did need to combine the sockets, you do not need to deconflict the packet IDs if you use the peer address as an identifier. If the packet came from a known tracker, parse it as a tracker packet using tracker protocol IDs. If the packet came from anywhere else, parse it as a Descent netgame packet.