The mesh is an underlay for data sync within Ditto, operating independently of your queries and sync subscriptions. Data updates propagate through the mesh automatically, provided your sync subscriptions match.

Whether you have two devices or two thousand devices in your mesh, Ditto incorporates several algorithms to maintain an optimal mesh network at all times.

This article provides an overview of the very basics of Ditto's mesh technology, covering key topics such as:

Upon initiating the sync process by invoking the startSync function in your app, peers with the same app ID immediately form a mesh network using a mixture of communication transports, each with its advantages and disadvantages. For example, Ditto prioritizes Wi-Fi for its high bandwidth and only falls back to Bluetooth LE when needed to take advantage of its longer-range capabilities.

Unlike typical home networks — which represent a star topology where all devices connect directly to a central router, switch, or access point — a peer-to-peer mesh network offers multiple pathways for communication.

Here's a quick video overview by Ditto's Network Transports Team Lead, Tom Karpiniec:

Ditto leverages an array of communication transports, supporting a variety of use cases and end-user devices. Communication transports are networking protocols that facilitate data transmission across different environments. For instance, using the local area network (LAN) transport for data movement in an office-like setting.

Which transports Ditto supports depends on what kind of device or Small Peer SDK you are using, for example:

While many transports are set up automatically, others, such as WebSocket, if configured with the Big Peer, require that you manually configure them in your app. 

Ditto incorporates a multiplexer inside the peer-to-peer mesh network to facilitate data sync.

Developed by Ditto, the multiplexer is an intelligent sync machine that seamlessly switches between active transport types as needed, without duplicating data.

In addition, the multiplexer breaks down data packets into small fragments and then, once received on the other side, reassembles them.

When all peers connected in the mesh need to share the same view of the data, Ditto initiates the flood-fill process to multihop data from one connected peer to another connected peer by way of intermediate “hops” along a given path.

Ditto's security relies on digital identities for peer-to-peer authentication and access control permissions.

Each instance of Ditto running in your app is assigned a random universally unique identifier (UUID). This string of alphanumeric characters uniquely identifies your app across the Ditto platform and other integrated systems and environments, including:

Using Ditto's onlinePlayground identity, you can sync with other peers who share the same app ID and read and write to collections without the hassle of setting up your own authentication.

A challenge arises in offline scenarios when two or more peers make edits independently and the data values stored by each peer diverge over time.

Referred to as conflict resolution, Ditto's process of addressing concurrency conflicts involves a combination of a metadata database and guiding principles, as follows.

The multiple replicas that result from a single partition are spread across virtual and relevant physical server nodes; that is, the Big Peer cloud deployment and local Ditto stores of subscribing Small Peers.

By default, Ditto does not automatically replicate data to peers. Instead, peers subscribe to changes and, using a query that you've defined, indicate the data they're interested in watching for changes. Once a change is observed somewhere in the mesh, only the delta matching your query replicates to other subscribing peers.

In simpler terms, replication involves a subscribing peer selectively "pulling" data from other peers, rather than remote peers automatically "pushing" data to it.

Partitioning and replication are central to ensuring rapid and dependable data access for your end users. With Ditto's query subscription system, devices are able to sync both Ditto document and attachment objects efficiently and intelligently.

For a direct explanation of the query subscription system that controls Ditto's data sync service, watch the following video on the functionality of subscriptions. In this video, the tech lead of Ditto's replication team discusses the synchronization process between two peers — one with an empty document set and the other with seven billion documents:

The Ditto SDK features a configuration structure called TransportConfig, which is stored within the main Ditto object. By default, if you don't make any changes to this configuration, Ditto will automatically enable all available peer-to-peer transports.

If you create a new TransportConfig, it has three main sections:

Most apps will only need to configure the peerToPeer and WebSocket settings.

The listen parameters provide support for unusual scenarios such as web browser clients on fully offline networks. Please use these only as directed by Ditto. If misconfigured, the listener features could circumvent Ditto’s usual encryption and access control.

When Ditto starts syncing it advertises itself on all enabled peer-to-peer transports. This advertisement is transmitted in different ways depending on the transport but it always involves two small pieces of information.

All devices running the same app will have the same App ID Hash so they know they should connect. In the rare event of a hash collision, Ditto may try to connect to a different app, but verification will fail and the connection will be canceled immediately.

If you are monitoring network traffic you might come across a Ditto Announce. This is a Ditto-specific advertisement format that contains basic information about the device. This provides hints to Ditto so that it can construct a good mesh quickly and efficiently.

The Network ID is randomized each time Ditto starts up. It enables peers to identify each other with high probability across all transports. If Peer A connects to Peer B over Wi-Fi they know each other’s Network IDs, so Peer B can avoid creating a duplicate connection in the reverse direction.