Architecture Overview

Resonite is built on a novel engine architecture, which makes real-time networking, persistence and interoperability a solid guarantee without any extra work involved. At the core are various programming primitives, which are equivalents of variables, references, arrays, dictionaries, trees and other common building blocks, but designed so they can be automatically replicated over network or persisted. The engine itself is built from these building blocks, giving access and automatic replication to all of its core functions and components

Worlds & Sessions

Currently a hosting unit is a world. Each world is a separate session to which other clients can connect to. Resonite automatically replicates the world and any changes to it in real-time to the connected users. Real-time replication uses a highly efficient binary protocol, designed to save processing and memory resources as well as network bandwidth, at the cost of compatibility—it assumes that both clients have the same version of the code. Sessions that are using a different version of the code are listed as incompatible.

When a user starts a new session for a world, they become the host, with other users connecting to them as clients. Resonite has a NAT punch-through server to allows the clients to initially connect to each other even without a public IP and without opening ports, but all the subsequent communication is directly between the clients. There is also a packet relay server which is used as a fallback if NAT punch-through fails.

When a new instance is started, any connections to that session use the real-time synchronization protocol, mediated by the person who opened the persisted world (the host). Multiple users can start multiple instances from the same persistent copy, and each will be the host of their own session. If the user also has write rights for the corresponding record (e.g. it belongs to them or their group), they can save the running instance and overwrite the previous persisted copy, affecting any subsequent instances open from that record. Users who do not own the world cannot overwrite it, but they can save their own copy if it is permitted by the world.

Worlds and the content within them can be saved either to the local machine, where they are then stored on the local hard drive, or to the cloud, which persists them using a corresponding "record" on Resonite's official servers and uploads the assets representing the serialized world's data structure (as well as any other assets it references like textures and meshes). The assets are de-duplicated, so referencing the same texture from multiple worlds only counts once against user's cloud quota and needs to be only uploaded once.

Persistence

For persistence, a different binary serialization mode is used than the real-time synchronization, which is designed for both forwards and backwards compatibility across Resonite versions. When older versions of saved content is loaded, is is automatically updated to conform to the current version.

Any worlds or items saved in Resonite are saved in this format, which ensures that they can be safely opened with a different version of Resonite even when 'breaking' changes are introduced. Each world is saved to a single file, called a Resonite Record Path, referred to by an URL, same as any other asset (texture, mesh, sound...). Metadata in the Resonite record (resrec) is stored using a compressed bson format.

Users can export content from Resonite via Resonite packages which package the Resonite record and any required assets into a single self-contained zipped archive. This is the recommended way to store and share Resonite content outside of Resonite (e.g. distributing avatars or offline backups).

Access Control

Each cloud record also has access information. By default the API server will refuse to send any information about the record unless the user is signed in and the record belongs to them. When publishing a world, the record is marked as public and can be submitted to a public listing, which makes it show up in a hub. Making it public lets other users download the asset representing the world and start a new instance of it.

Asset Gathering

Resonite also has an asset gathering protocol, which can download assets from various sources. Assets can be stored on common http(s) and ftp servers and directly download from those by each client, or in the Resonite asset storage (resdb:// URL). When a new asset is first imported, a unique URL with the local:// scheme is generated. Those are transferred completely within the session itself, without going through any Resonite's cloud storage servers.

When saving a world or item to any cloud location (e.g. cloud home, inventory or a message) Resonite creates a corresponding record and uploads any local:// assets to the Resonite asset database, overwriting the URL's to resdb:// in the process, so they can be downloaded by anyone without the need for the original hosting computer to be running and have an active connection.