Question: TURN server integrated into pvpgn?

[timfel]

As far as I can tell, the pvpgn server pretty much gives me the battle.net protocol, but the actual in-game connectivity is still up to the game. I'm currently making Stratagus support pvpgn via the bnet protocol as an online service. Stratagus uses p2p UDP (similar to Warcraft 2) for its games, which is an issue with modern network topology. Would it make sense to integrate a TURN relay server into pvpgn? I.e., when a client is authenticated and starts advertising a game, it can allocate a relay for UDP packages on the pvpgn server with a dynamically allocated port. Other clients can then connect to that custom port on the pvpgn host and it will forward to the server that opened the game, and also allocate dynamic relay ports for those clients. So for the game, it will be (almost) transparent, and the p2p packages are just relayed via the public IP of the pvpgn host.

[cen1]

I tried something similar but using reverse ssh. I allocated a random port to the client and then replaced inet addresses in pvpgn game advertise packets with the ssh server ip and allocated port. Long story short, for whatever reason it did not work even though everything "seemed" allright in tcpdumps. W3 instances could not negotiate a handshake. If you could get a proof of concept going I think it would be quite interesting to see.

edit: correction, it worked for W3 custom games but not for meele (via the w3route proto). Since my primary goal was to add support for meele I gave up after a few weeks.

[timfel]

@cen1 what I propose wouldn't help with existing games - there would be a new package to allocate the relay resources that only custom clients would implement.

[timfel]

No, that's not quite correct - we could of course always allocate a port for udp relay for every newly advertised game. Any connection to that port would then also have to get an automatic allocation, though. I'm not sure it's wise to do this, it'll mean a lot more resource usage on the server.

[cen1]

Could this be deployed as a seperate executable and not be a part of core bnetd process? I imagine you would want to deploy this on a seperate (regional) server since it actually effects gaming latency, while pvpgn does not in itself. You would just need a bit of an API interaction to check for authentication against pvpgn.

[timfel]

Yeah, that's another option I thought about. The question is how this interacts with the client. Do we want it transparent (i.e., should it work e.g. with original WCII:BNE) or not? I think if we want it to be transparent, I think it has to be inside the pvpgn process.

[vioviorel]

me and cen we test a solution thatwork for custom games. but for meele there was a problem.