Difference between this and netcode.io

[tomqwertysdsad]

I understand that this is built on netcode.io and reliable.io but I'm not sure what exactly this provides over those two libraries.

Also would either this or netcode.io be suitable for a turn based game like worms? From my understanding netcode.io would be but im not sure what yojimbo offers in addition... is it more action game focused?

[gafferongames]

Good question!

netcode.io provides a portable C-level client/server abstraction, with connection slots, and packet encryption and authentication (so only authenticated clients can connect to servers). It was designed to be very portable, and as a standard, so it is binary compatible across different implementations written in different languages (eg. C, Rust, Golang...)

reliable.io implements an ack system, so you know which UDP packets have been received by the other side, plus, MTU fragmentation and re-assembly, so you could send for example, a 16k packet, and have that packet get split up into 1100 byte pieces and re-assembled on the other side for you. It's also written in C and is designed to be easily ported to different languages, but nobody has ported it to other languages yet.

Yojimbo provides a bitpacker and serialization system built on C++ templates, plus a reliable-ordered channel that supports messages and large blocks. It also provides a client/server system that wraps up netcode.io, but in such a way that you could replace that with your own client/server implementation if you wanted to.

Yojimbo is basically the low-level network library that I would use as the foundation for writing any UDP game netcode in C++ (eg. FPS, deterministic lockstep, whatever...), but it is fundamentally designed with FPS characteristics in mind. If you hired me to write an FPS, and you asked me to write the low-level network library to support that, yojimbo is what would pop out (after about a year of hard work...). But that doesn't mean this library is only for action games, it can do all types, except perhaps, MMO.

So which library should you use?

If you just want a low-level client/server connection with encrypted packets, and don't need anything other than unreliable-unordered packets, then netcode.io is the library you want to use.

If you just want packet acks to add to your existing low-level network library, or perhaps if you are using netcode.io in a language other than C/C++, and you want packet acks, then reliable.io is good for you (but you would have to port it to that language to use it, or create bindings for it in that language...)

If you are working in C++ you should probably just use Yojimbo. If you are not working in C++, then you cannot use Yojimbo.

cheers

• Glenn

[tomqwertysdsad]

Thank you for taking the time to give a full response, I appreciate it.

The only thing I think you didn't explain is the yojimbo matcher. My understanding is you have a HTTP web server which is essentially just an authentication server where the client uses to get a token for access to the game servers. However, the matcher appears to also be a web service, where does this fit into the flow?

[gafferongames]

Yes, the yojimbo matcher is just a wrapper around the netcode.io connect tokens.

The basic idea is this:

1. You have a web backend for your game (eg. to provide sign in and authentication)

2. You have a set of dedicated servers running in a data center or in the cloud (try www.multiplay.com)

3. You have your own matchmaker that tracks the set of dedicated servers and can determine based on a client's request, the set of dedicated servers that best satisfy that request (eg. same game mode, close to player, available slot for a player, other players on the server have similar skills, whatever...)

4. When a client that is authenticated with the web backend wants to play, they request a match from the web backend, this basically just returns a connect token, which is a cryptographically secure way to give the client a list of dedicated server IP addresses to connect to.

5. The yojimbo server only allows clients to connect with a connect token. This enforces the requirement that only signed in and authenticated clients can connect to dedicated servers. Because you are paying for dedicated servers, trust me, you want this.

cheers

• Glenn

[gafferongames]

In short, both yojimbo and netcode.io are designed around a situation where you are hosting dedicated servers for your game. If you aren't doing that, you won't find these libraries to be a good fit.

cheers

[tomqwertysdsad]

This looks to be perfect for me then. Thanks for clearing up my confusion.

[tomqwertysdsad]

@gafferongames Just had another look over this and wondered on how you would handle a "proper" matchmaking scenario.

For example, lets say we want to match players against each other based on some ELO/TrueSkill rating. As you may know games like CS:GO, League of Legends etc all have queue times which often take 3-5 minutes for the average person.

Based on what you said above and how the matcher.go appears to be working this would seem to cause a problem by having the client wait 3-5 minutes for a http response. I don't know if this is what you intended to imply above (maybe I am just misunderstanding).

Anyhow, I had a couple ideas and would like to hear any ideas you have.

Idea one:

• Authenticate the user (HTTP request 1)
• Request a connection token which returns a matchmaking server ip (HTTP request 2)
• Client connects to the matchmaking server to join the queue (UDP)
• When match is found it sends back another connection token with one server ip for that match

Idea two:

• Authenticate the user (HTTP request 1)
• Request to join the queue (HTTP request 2)
• Poll a HTTP endpoint while in queue, eventually it will return a connection token with the server to play on.

Idea two is probably easier/quicker to implement and only involves one connection token but does involve a lot more HTTP requests.

[gafferongames]

Idea two looks good. Keep the client updated with various HTTP responses while they are searching for a match, in the queue etc. Separate out the lobby/queue (REST API), from the in-game (UDP stuff). Don't connect to a server until you have a match ready for at least a subset of players. You want to keep the number of servers allocated down to a minimum vs. having servers active while players are in lobbies/queues.

[tomqwertysdsad]

Good point, hadn't fully considered the cost implications of option one. Also, a REST api is much easier to manage.

Thanks for the reply as usual.

[tomqwertysdsad]

Thought I'd just tag another question on the back of this issue.

I have been reading through other issues and couldn't find an answer to a question about AdvanceTime.

AdvanceTime seems to just set a time which is used in packets? Does the time value need to be kept in sync between the Client and Server? For example, I have my client loop running as fast as possible (variable frame rate) which means AdvanceTime will be changing at a variable rate (whatever the dt is each frame). Meanwhile, the server will be running at a fixed rate, say 20Hz. Is this ok? Can the client and server be sending packets at different frequencies and will the variable rate of the client cause problems?

If so, is the suggested method to have a seperate thread on the client which also has a fixed frequency the same as the server?

Thanks.

[gafferongames]

Please create new issues for each question you have. No, advance time is just a local time used to do things like, timeouts.

[gafferongames]

Yes it's OK to have the server running at a different rate if you want. client and server have no synchronization of time. The time is just local for timeouts and resends of messages and such. So it's just a wall clock on client and server.

[tomqwertysdsad]

Thanks for the quick response, this answers my question.

I will create new issues in the future. Apologies.

[gafferongames]

no worries at all