Star Citizen, Squadron 42 & Theatres of War News, Guides, Videos & Gameplay by BoredGamer

Star Citizen – What Are We Getting With Server Meshing?

Star Citizen Dev Response – We have had a lot of information on iCache recently, this is the item cache that is replacing the current way that Star Citizen tracks items, assets, ships etcc… with a new robust service and is a stepping stone to true persistence ingame as well as server meshing.

There was a thread on Spectrum Does each game server have its own iCache instance which will partially copy sections of the global database service for quick access? I thought iCache was going to be a horizontally scaled database service that all game servers would be able to access. From the recent Calling All Devs episode it sounds more like each game servers will have its own iCache instance on its drive for quick read/write speeds to the database. Each iCache instance would replicate relevant data from the main global database based on which sections of the game world are loaded on that server?

Chad Mckinney Replied with a load of answers and info:

icache is a fleet of services that are as you say horizontally scaled, that can be dynamically spun/up down according to requirement, and their numbers are entirely decoupled from specific servers instances. Servers don’t have their own databases, but shards (in our usage this will be a collection of servers in a mesh working together) will have their own records, and the items and variable DB for these shards will be effectively separated from each other since for the most part shards don’t interact with eachother (with the corner case being players moving between shards between sessions).

Something I think that was maybe slightly lost in the editing of the episode is that we won’t be jumping immediately to a global single shard, but instead this will be a gradual process. Once we introduce meshing the meshes won’t be as large and dense as our goals of region sized shards and possibly a single global shard. Instead they will act kind of like our server instances, but allowing us to bring up the player count from 50. As we test, make improvements, optimize, fix bugs, etc.. we’ll be able to bring up the player counts to hit the larger goals we are aiming for, but it won’t be day 1.

Will meshed servers access each others database to access data or will they constantly exchange relevant data directly between each other?

The servers in a mesh will be communicating with each other constantly, similarly to how clients and servers communicate with each other constantly, but persistence based queries will go to the icache, not other server nodes in the mesh.

So what will the Tier 0 implementation of the Shards & Servers Look like? 

Shard’s persistence records are separate so their view of the world is decoupled. This is what I was getting at when I mentioned world lines in the video but it got paired down to miss some of the meaning I was intending. The goal is to get the player density as high as possible so players play their entire game experience with SC in a single shard. It may be that they don’t ever go into a shard in EU or Asia (TBD how region based sharding will work, just random examples) but from that player’s perspective they will see a consistent view of the world, and their friends will as well as long as they play in the same region (and before we have region based shards we can use match making techniques to get a similar effect).

 It seems like iCache, Meshing, and Persistence all required one another – Does Full Persistence require Server Meshing (and vice versa?) How does that work?

In some sense they do all require each other to work in the final version we are intended, which is why it can be sometimes confusing to explain as we both have to explain the final vision of the system and simultaneously break down how we phase in segments of the whole system in such a way they can work without the rest of the system. In short, the goal is server meshing, but for that we require both global persistence and icache. Icache doesn’t technically require server meshing, but you aren’t entirely wrong that it appears that there is some relationship to it needing some concept of a shard to start with. The way this works is by effectively treating single server instances as a single server node mesh to start with. Global persistence is in right now in that the global state of the world is persisted, but only per server instance, and only in internal memory (not stored out to a data base). With icache we are first moving this server instance based persistence out of server memory and into a proper DB, where it will be parsed out according to shards (as I mentioned above). And as I said, before we get server meshing working that will effectively mean that each server instance is a single server mesh which means it will also have it’s own shard persistence record. Once we get server meshing rolling then the shards will increase server density (first statically, later dynamically) and then things start to look like our final goal, up until then it will be a series of incremental steps and some temporary work to hold us up as we get there. It’s like building a ladder while climbing it simultaneously.

Finally there was a Question asking if Star Citizen still uses “Diffusion” that

intelligently pro-actively distributes data to the server & client with Chad Answering We do still use diffusion, it is currently leveraged in many of our backend services such as the icache system.

Chad is really killing it with the community interaction and dev responses! You are a legend and it’s really great to see Devs get involved like that.