Replacing underlying networking methods with Steam P2P

Hi there, I am currently working on a game that requires to have Steam’s P2P connectivity, but I am completely lost as to where to look in order to implement it. As far as I am aware, my problem is not really about “rewriting entire networking codebase” but rather replacing some underlying send/receive methods with connectivity handling. Could anybody point me in the right direction where should I go with this issue? I tried finding any info about any efforts that could have been made in this direction but could not find anything.

So after searching for a while, I came across this PR that seems to be trying to go in the same direction as I am, but it seems like it is a forgotten one-man project with almost no recognition. If by some miracle ArnisLielturks or somebody from the main team is reading this, or my comment on that pull, I hope you will be able to tell more about this because P2P is practically the only thing that is preventing my team from migrating to this amazing engine.

Welcome to the community, @Stuur!

I’m sure @Miegamicis will be able to at least provide some handles as soon as he reads this. Which likely does not require a miracle, just a little patience.

See also:

Thanks for the welcoming Sorry if I sound impatient or exaggerated, but I was having a blast prototyping and working with the source code while testing the grounds and I simply can’t wait to start working on the game after that. About the issue that you have linked - it seems to explain the reasoning between the split into different projects, but it does not really answer questions that I want to ask. Now that @Miegamicis is pinged, the best thing that I could do is to formulate them in the clearest way possible.

1. How “production-ready” is the pull from august 2019 and is there any news on why was it not included in the main branch yet, or what are the major roadblocks that prevent that from happening.
2. Are there any major API differences from the Steam’s P2P in the comparison to the current implementation.
3. Is it feasible to use the current implementation in order to replicate server-client as if we were talking about dedicated servers? The only reason why we are using P2P and not dedicated servers because we need to have a fallback if NAT punch though fails, which is exactly what Steam provides with their P2P traffic relay upon failure.

I’m not sure how much @Miegamicis knows about the Steam API. @Enhex might be more knowledgeable in that regard, but I don’t know if he has any experience implementing (P2P) multiplayer.

Don’t be surprised if you’ll turn out to be the Steam P2P expert.

Hi! Glad you’re interested in the P2P stuff.

So let’s get straight to the questions:

1. Depends what you’re thinking when talking about “production-ready” P2P. The thing that I didn’t try to solve in that PR is the replication which tends to be quite tricky to get it right since the current server-client replication implementation gets out of sync when we’re talking about it in P2P mode. There is no problem with updates that are sent out periodically (like node position, rotation etc). The PR in it’s current state is not yet ready to be merged in master.

2. Not that familiar with Steam’s P2P, might need to check that out.

3. The PR and the linked P2P Multiplayer forum post contains the more advanced sample which does in fact act like a dedicated server, the only difference is that the server is the peer which is elected as the host. By default the peer with the longest connection time is elected. And it looks like the SLikeNet library also has a relay mode available, but haven’t yet tried that, for more information see the UDP proxy section of the page http://www.raknet.net/raknet/manual/natpunchthrough.html

Let me know if there’s anything else that you’d like to know. In the meantime I might update p2p branch to reflect latest changes in the master in few days.

1. I am talking about how safe and reliable is it to use current implementation during actual development, or is it in more of an “open beta” currently?
2. All the functionality that I would need to port to SteamAPI is just initing/blocking/closing connection and sending/receiving data, nothing more, nothing less. I am asking about this because most of your code is written on top of RestAPI from Digital Ocean/SLikeNet, and if you were using that functionality in somewhat basic “replicatable” way that is not fully bound to the architecture that you have, then it should not be a problem to port into Steam’s API.
3. I see, so it should not be that big of a problem then.

1. I am talking about how safe and reliable is it to use current implementation during actual development, or is it in more of an “open beta” currently?
2. All the functionality that I would need to port to SteamAPI is just initing/blocking/closing connection and sending/receiving data, nothing more, nothing less. I am asking about this because most of your code is written on top of RestAPI from Digital Ocean/SLikeNet, and if you were using that functionality in somewhat basic “replicatable” way that is not fully bound to the architecture that you have, then it should not be a problem to port into Steam’s API.

1. The SLikeNet implementation itself is pretty solid, so I would say you can safely use it in development but there are things regarding the code style that are yet to be changed.

2. The services that are needed for the P2P (NAT punchtrough master server, sessions master server) are both available as docker images, so there should not be any problem bringing them up anywhere else plus the session master server is really basic and would have to be rewritten from scratch if you plan to go live with it. But I must say that Steams API is probably more polished and could scale more easily than any other self built stuff. Our SLikeNet implementation is cross-platform, so it will run anywhere (except for the web), not sure about Steam’s API capabilities but if you’re planning to launch only desktop version of the app then it shouldn’t cause any issues.

Thanks for the info! I will definitely look into adding P2P with your implementation.

I saw you doing some WS commits in repo.
So I’m curiuos: what are your overall plans regarding networking?
I’m talking about things you want to get into master of main repo.

First of all I hope to get networking completely supported in web builds (without humblenet lib). I know there are still some issues with the web regarding user input that I have been postponing but because of limited time that I have for this project I tend to do the most interesting stuff first.

After that I don’t really know, I know we talked a lot about cleaning networking stuff from engine parts that are not directly related to it, but I still have some research to do before figuring out the best solution for it.

Are you going to support networking in web transparently (so that user won’t have to treat web in different way)? Or user will have to do some extra work to get networking?

Plan to create it in a way that it works just as it is with the current network implementation. Compile the project and you’re good to go. But there is some JS code that is directly injected in the C++ code, maybe I should expose that in the new emscripten shell.

Regarding current implementation I added some extra methods to start either UDP or TCP(WS) server and same goes for the clients. The previous Connect method connects to UDP server and ConnectWS connects to the WS server and all the new functionality can be enabled by the URHO3D_WEBSOCKETS flag. So I guess there is a bit of extra work needed for the users to understand which way to go. BTW my current implementation supports server which can actually run both protocols at the same time.

If web builds can work without slikenet, maybe it desktop builds could also do networking directly? Does it make sense to keep slikenet around if it’s features arent really used?

I’m not sure. Even though we use only small portion of SLikeNet’s capabilities we do still use them. Rewriting them would take a while and I’m not sure I’m up for doing that.