Comments (13)
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
from yojimbo.
This looks to be perfect for me then. Thanks for clearing up my confusion.
from yojimbo.
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?
from yojimbo.
Yes, the yojimbo matcher is just a wrapper around the netcode.io connect tokens.
The basic idea is this:
-
You have a web backend for your game (eg. to provide sign in and authentication)
-
You have a set of dedicated servers running in a data center or in the cloud (try www.multiplay.com)
-
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...)
-
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.
-
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
from yojimbo.
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
from yojimbo.
@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.
from yojimbo.
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.
from yojimbo.
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.
from yojimbo.
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.
from yojimbo.
Please create new issues for each question you have. No, advance time is just a local time used to do things like, timeouts.
from yojimbo.
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.
from yojimbo.
Thanks for the quick response, this answers my question.
I will create new issues in the future. Apologies.
from yojimbo.
no worries at all
from yojimbo.
Related Issues (20)
- Updated official release HOT 2
- TLS Error on mac HOT 2
- Question - NAT Punch-through HOT 2
- Failed to Create Message Type and Serialize check failed HOT 4
- Windows: cannot connect while other clients are timing out HOT 4
- Client connection refused if it's time is > server time HOT 1
- Message Types vs Data Blocks HOT 1
- Ignoring late packets HOT 1
- Working on improving the vcpkg integration: libsodium and mbedtls versions? HOT 9
- Intended use of client messages HOT 5
- Sending arrays of variable size HOT 4
- Yojimbo linkage HOT 1
- Improve vcpkg usage experience HOT 4
- Large messages can clog ReliableOrderedChannel indefinitely HOT 3
- client.Disconnect() in loopback.cpp example HOT 2
- Building.md instructions not working for m1 mac HOT 3
- matcher docker doesn't seem to build anymore HOT 1
- Sending Large Block Sizes slow HOT 1
- NDA platforms HOT 1
- Problem with #if in yojimbo_reliable_ordered_channel.cpp HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yojimbo.