NAT piercing - Rough ETA? (question)

[Frooxius]

Hello!

I've been excitedly watching this project for a while, I'd love to switch to it as the primary transport protocol for my project.

Since we don't have dedicated servers yet, multiplayer sessions are user-hosted, so NAT piercing and relay servers are crucial.

I just wanted to ask if you have any rough estimate when this might be implemented?

Thanks for your time and hard work on this!

[zpostfacto]

I don't have a timeline yet, sorry. There are several really large features in the Steam version that are going to happen before this becomes a priority. I renamed this bug to track this as a feature and will update the roadmap to point to it.

Before this work begins, I think the connection classes need to be refactored a bit to separate the work of the logical connection from the lower level transport. I also have some very similar work I want to do to utilize the relays for Steam Link Anywhere.

When those two tasks done, I'll update this bug, because it might be something somebody else motivated could bite off, if they were interested.

[zpostfacto]

Finally working on this. Hopefully in a few weeks!

[zpostfacto]

@Frooxius @eddiejames @FrankStain @SnapperTT, or anybody else interested:

I have a beta version of this working. I'd like to work with somebody who has a good test case and who wants to test it. Anybody interested?

• You would need to provide your own rendezvous / signaling mechanism.
• It might be a bit arduous figuring out how to compile the google webrtc code.

I'm interested in what snags you hit.

Any takers?

[MitchDart]

Hi @fletcherdvalve, thanks for all your hardwork. This library is great! I am using it in a new project and we about 1 month in now. I was actually researching how to go about NAT punchthrough since our project is p2p. I would be keen to try out your beta however I'm not sure if I would be able to give much valuable feedback. I have never worked with NAT punch piercing before but definitely a fast learner!

[zpostfacto]

@MitchDart, if you or anybody else wants to try out this code, here is what would need to be done:

• You will need to provide your own signaling mechanism, as mentioned above. That is some low-bandwidth, non-latency-sensitive channel that peers can use for best-effort delivery of small messages. So this would go through your central service, however those peers are finding each other. In the Steam version of this API, Steam provides this. But you'll need to provide this. That is going to be an inherent requirement in any P2P setup. See ISteamNetworkingConnectionCustomSignaling and related functions that use it.

• You'll need to compile the webrtc code, and get ice_session.cpp to link against it. That is kind of an involved project, because google has their own very sophisticated toolchain system and you'll have to wade through that. I can share info on how we did it, but the version of webrtc that we started with is maybe a year or two old now. And so you are likely to hit new issues. Eventually, I'd like to have this project have a git reference to a particular webrtc release, and I'd make sure that ice_session.cpp would work with it. I have not done that work yet. I don't really know how much has changed since we grabbed a version of webrtc that ice_session.cpp runs against. We did try to make absolutely minimal changes, but we're accessing stuff at a relatively low level in their library, not at the surface API, so it's totally possible and reasonable for them to have shuffled stuff around.

[zpostfacto]

I'm gonna go ahead and close this issue. I added a new readme describing the P2P support, what is required, and what needs to be done. I added issue #117 to track the WebRTC compiling tasks.