Mesh Network

when you use ditto in your app, you don’t have to think about how your devices will connect in the peer to peer mesh network a device like an iphone will build an interconnected mesh all on its own as soon as you call startsync() , it fires up bluetooth low energy (le), scans for peers on the wi fi, and activates apple wireless direct link (awdl) to create high speed connections with nearby apple devices — using only one line of code the mesh is an underlay for data sync it operates independently of your queries and subscriptions data updates will propagate through the mesh automatically, provided your subscriptions match ditto contains several algorithms to maintain an optimal mesh automatically, whether you have two devices or two thousand many applications need to sync data with the big peer or an on premises server the ditto sdk uses peer to peer and big peer connections simultaneously, turning your mesh global this is as easy as setting your server’s url types of transports https //docs ditto live/ios/common/how it works/mesh network#types of transports ditto uses as many technologies as possible to communicate with other devices running your app these different modes, such as bluetooth le and local area network (lan), are called transports where possible ditto will create a mesh using a mixture of transports they offer different advantages and disadvantages for example, bluetooth le generally has a longer range but much lower bandwidth than wi fi therefore ditto uses wi fi when available and falls back to bluetooth le when it is not for an overview of performance and limitation by transport type, see docid 7gxlmuctx4vhm53kykwyp which transports are supported depends on what kind of device or sdk you are using some examples a mobile phone can use bluetooth le, lan, wi fi direct, or a websocket connection to a big peer server a web application running in a browser can use websocket a raspberry pi can use bluetooth le, lan, or websocket many transports will work automatically others like websocket require configuration for instructions, see docid\ iic3gevlppflwzt1sbljr discovering peers https //docs ditto live/ios/common/how it works/mesh network#discovering peers 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 app id hash announce all devices running the same app will have the same app id hash so they know they should connect to each other 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 cancelled immediately if you are monitoring network traffic you might come across a ditto announce this is a ditto specific advertisement format which contains basic information about the device this provides hints to ditto so that it can construct a good mesh quickly and efficiently q1racgxmbwogjgsgp771 q1 major protocol version 1 ra platform android cgxmbwog 32 bit network id jgsgp771 device name “sgp771” 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 making and breaking connections when a user opens your app the first thing they will see is how quickly it syncs the latest information ditto understands this when sync begins it uses all the transports aggressively to locate and connect to multiple potential peers concurrently at the same time, the existing peers will notice the newcomer’s arrival if they have capacity they will also establish connections to the new device together, these processes ensure that a new peer is integrated into the mesh as quickly as possible after this initial burst ditto must become more efficient a mobile phone has a finite battery each extra lan connection consumes more cpu time and more radio energy bluetooth is particularly constrained devices can manage only a handful of concurrent connections and each connection can take several seconds to initiate therefore in larger meshes, ditto must limit the number of interconnections, and choose wisely at the same time, ditto must not have too few connections otherwise islanding can occur, where different groups of devices in the same room are connected in individual clusters if there is no connection between those groups they will not sync data with each other ditto avoids islanding using two techniques, neither of which require central coordination first, a reasonably dense mesh is preferred so that islanding is improbable second, a random churn means that devices will slowly change which peers they are connected to this ensures that even if an island did form, it would likely only last a few seconds next, certain optimizations are possible imagine there are two candidate peers for a bluetooth connection but you only have the capacity for one if you are already connected to one of those peers via wifi, then we should spend our bluetooth connection on the other peer, to improve the diversity of the mesh now, imagine the same scenario except we have capacity for two bluetooth connections this time we should connect to both of them the bluetooth connection where we have wifi will sit idle for now, but if that wifi connection goes away in the future then we can immediately failover to the pre established bluetooth connection the user won't even notice that anything happened sounds complicated? don’t worry about it everything described here is built into ditto and your app will do this completely automatically all you need to do is enable your transports and ditto will make the best possible use of them using bandwidth intelligently https //docs ditto live/ios/common/how it works/mesh network#using bandwidth intelligently in smaller meshes, ditto will often create multiple connections to the same peer using different transports this might look wasteful but it provides important performance benefits the transports race against each other to establish a connection as soon as we get the first one, data sync can begin this means lower latency for initial sync the fastest connection is preferred to transfer data, so large updates sync as quickly as possible unneeded slower connections like bluetooth are left idle, which means the limited radio bandwidth is reserved for those peers that really need it if the fastest connection is lost, the next best option is ready to go, reducing or eliminating the gap when no sync is possible the seamless switching between transports relies on a ditto component called the multiplexer, which is described in detail in a https //www ditto live/blog/the new network multiplexer the multiplexer uses one transport at a time with failover in future versions, this feature will enable more complex scenarios such as load balancing across multiple routes and lossy transports servers and the big peer https //docs ditto live/ios/common/how it works/mesh network#servers and the big peer in addition to peer to peer transports like bluetooth, a cloud or on prem server can be configured by specifying its url at ditto, we call a server like this a big peer , while regular sdks are small peers big peers are especially important for users who want to use ditto in a web browser since web browsers have very limited peer to peer capabilities the javascript sdk can be configured with the big peer that should be used for sync an sdk can sync directly with a big peer, or locally with small peers, or with both at the same time, acting as a bridge for devices that don’t have an internet connection configuring the mesh https //docs ditto live/ios/common/how it works/mesh network#configuring the mesh every ditto sdk has a configuration structure called transportconfig , which lives in the main ditto object if you don’t change the default configuration ditto will enable all available peer to peer transports if you create a new transportconfig it has three main sections peertopeer connect listen 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 for more information, see docid\ iic3gevlppflwzt1sbljr