How does this compare to other rUDP implementations?

[warvstar]

Such as QUIC, KCP, Laminar, ENET, WebRTC datachannels, RakNet?

[anchor76]

we just used RakNet/SlikeNet, so i can compare to it. (feel free to correct me if i'm wrong):

disadvantages: RakNet has better and cleaner API than GameNetworkingSockets. RakNet has no dependencies, GameNetworkingSockets has many, and the compilation sometimes difficult. RakNet has built in real p2p feature with natpunchthrough plugin, if you have a game server, no need to use STUN servers.

advantages: it seems GameNetworkingSockets has full ipv6 support, actively developed, and very well tested. (RakNet has broken ipv6, it has several bugs, and the development ceased since years.)

so RakNet is a "full-service-in-one-lib" solution, what is very convenient, but unfortunately outdated. GameNetworkingSockets was sliced out from Steam ecosystem, and the p2p feature seems a bit immature yet, you have to make your own signaling solution, what is inconvenient after RakNet.

i hope the authors will implement a default signaling as they planning :)

[zpostfacto]

It'd be great for anybody else with opinions and info to comment on this issue. I'd like to write a comparison summary to help people decide what is the best lib for their needs. Also reading these descriptions of the pros and cons of different libs helps understand what features are important to people. For example, browser interop is probably a big deal for some people, and that's something I've thought about how best to implement. It's interesting that dependencies on protobuf and opensll is a disadvantage. The alternative to taking a dependency on a widely used crypto library is rolling your own crypto.

@anchor76 I'm not too familiar with what raknet offers. What signaling service do you get out of the box? Presumably you still have to run your own signaling servers. A signaling service is not something that can be provided by a "library". Do you know what they provide?

[anchor76]

@fletcherdvalve thanks for your reaction on my comment.

ofcourse it's my subjective opinion, and i think GameNetworkingSockets is a great opensource networking lib, if not the best. i see the networking from mobile game development side, what is very specific i know. we migrating our game from raknet/slikenet to GameNetworkingSockets. we have our own encryption, what is fast enough for a realtime mobile game.

i'm still learning this lib, so feel free to correct me if i'm wrong:

about the API:

in raknet you have one p2p instance, and you can connect to any other peer, or to the game server. you getting all messages in one loop, the connect/disconnect/etc messages also arrives as data message, no need to poll them separately. this is very clean, and easy. in GameNetworkingSockets at server side i made a listening socket, and at game side i connecting to server with the ConnectByIPAddress() function. for the p2p connection, i made a separated p2p listening socket, and i have to poll all peer connection one by one. plus polling the server connection. this is more complicated, but i can accept it ofcourse. (i think its possible to make a small wrapper class to make it raknet like, but the migration is not finished yet and i'm not sure about the final solution)

about the p2p signalling:

raknet has a natpunchtrough server what is free to use, but we not using that, because we have our own game server. it's just a plugin what you can turn on at server and game side. the signalling channel is the persistent game-server connection. in case of failed p2p connection, our server offering relaying.

one more thing: you can drop raknet sources into any project on any platform, and it compiles fine. no need to compile thousands of sources, or make separated lib(s). GameNetworkingSockets itself is really tiny, only the dependencies makes it relatively big. it's also a minor thing, and not really important.

so why we choose GameNetworkingSockets ?

• ipv6 support. (Apple requires full ipv6 support on iOS)
• p2p connection is essential for us. less relaying = much simpler and cheaper infrastructure. plus faster data transfer in multiplayer match.

after we finished the migration, i can come up with ideas. : )

thanks for the attention.

[zpostfacto]

thanks for your reaction on my comment

Of course - it's my goal to make this lib useful and to have as many people use it as possible, so this sort of comparison and feedback is very welcome.

and i have to poll all peer connection one by one

You might look at poll groups. They are created for just this purpose.

the signalling channel is the persistent game-server connection

If you already have a connection to your gameserver that knows how to relay the signals, it shouldn't be that hard to make a custom signaling object to plumb this up so that this connection does the signaling. What does this look like in Raknet? Can you be a bit more specific what Raknet is providing that you think it might be a good idea for me to add?

[anchor76]

yes, with game server the signalling is very simple.

poll groups! how could i forget it. with this, i can't see too much difference between raknet and GameNetworkingSockets connection handling mechanism. you have to implement almost the same extra features.

question 1: is it possible to change the disconnection delay for existing connections? (we would like to switch between 5 and 30 sec disconnection delay values for existing p2p connections)

question 2: how GameNetworkingSockets is dealing with huge amount of connections? i mean more hundred connections at server side. is it okay? we dropped another network lib because it was designed for 10-20 connections maximum, then we found GameNetworkingSockets

[zpostfacto]

is it possible to change the disconnection delay for existing connections

Yes, you should be able to change k_ESteamNetworkingConfig_TimeoutInitial and k_ESteamNetworkingConfig_TimeoutConnected on a per connection basis, dynamically if necessary.

how GameNetworkingSockets is dealing with huge amount of connections

That should not be a problem. I think Rust has about this many connections and recently started using this lib. BattleRite was also using this lib for a while, and had a server that hosted many games at once. The one problem I might see is if you are trying to make API calls from many different threads. This library uses a single global lock, and so this lib will not be performant with that style of programming. (See #50)

If you end up with very many UDP sockets, you might end up with a problem with polling them all efficiently at the low layer. But typically a server just accepting connections from many clients will only have a single socket open and they all use the same socket, and it will be efficient. If you have 100 P2P connections.....I am not sure what performance issues you might hit in webrtc code. Maybe none.

[zpostfacto]

I'm not sure this issue is serving any purpose. If anybody wants to type up a comparison with pros and cons, I would add it to the README