vacp2p/vac.dev-experimental-old
1
0
Fork 0
mirror of https://github.com/vacp2p/vac.dev-experimental-old.git synced 2025-02-27 12:30:32 +00:00
Code Issues Packages Projects Releases Wiki Activity
vac.dev-experimental-old/p2p-data-sync-for-mobile.html

724 lines
33 KiB
HTML
Raw Normal View History

Updates
2021-09-02 21:14:19 +00:00
<!DOCTYPE html>
<html class="h-full" lang="en-US">
<head>
<title>Vac - P2P Data Sync for Mobile</title>
<meta charset="utf-8" />
<meta http-equiv="x-ua-compatible" content="ie=edge" />
<title>Vac</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link
rel="shortcut icon"
href="/assets/img/favicon.png"
type="image/png"
/>
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link
href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,600;0,700;1,400;1,600&display=swap"
rel="stylesheet"
/>
<link rel="stylesheet" href="/assets/css/style.css" />
</head>
<body class="h-full flex flex-col">
<div
class="flex-grow container max-w-screen-xl mx-auto px-5 md:px-12 lg:pt-6"
>
<header>
<div class="container max-w-screen-xl sm:border-b">
<div
class="
nav-section
flex
justify-between
items-center
py-3
md:py-5
lg:py-10
"
>
<div class="logo md:pr-8 l:p-0">
<a href="/"
><img src="/assets/img/logo.png"
/></a>
</div>
<div class="flex justify-between items-center w-9/12">
<div class="burger block sm:hidden z-50">
<button
class="
burger__button burger__button--open
fixed
top-2
right-5
w-12
h-12
"
type="button"
aria-label="Mobile menu button"
>
<img
class="burger__icon"
src="/assets/img/burger.svg"
alt="Open menu button"
/>
</button>
<button
class="
burger__button burger__button--close
hidden
fixed
top-2
right-5
w-12
h-12
"
type="button"
aria-label="Close mobile menu button"
>
<img
class="burger__icon burger__icon--close"
src="/assets/img/close.svg"
alt="Close menu button"
/>
</button>
</div>
<nav class="nav max-w-screen-xm md:max-w-screen-sl container">
<ul
class="
nav__list
hidden
sm:flex
justify-between
container
text-xs
font-semibold
md:pr-8
l:p-0
"
>
<li class="hover:opacity-50">
<a class="nav__link" href="/#work">Work</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/#about">About</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/#join">Join VAC</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/research-log">Research log</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/media">Media</a>
</li>
<li class="hover:opacity-50">
<a href="https://specs.vac.dev" target="_blank" rel="noopener noreferrer"
>Specs</a
>
</li>
<li class="hover:opacity-50">
<a href="https://forum.vac.dev/" target="_blank" rel="noopener noreferrer"
>Forum</a
>
</li>
</ul>
</nav>
<ul class="social items-center hidden md:flex">
<li class="pr-5">
<a href="https://twitter.com/vacp2p" target="_blank" rel="noopener noreferrer"
><svg
width="25"
height="21"
viewBox="0 0 25 21"
fill="none"
xmlns="http://www.w3.org/2000/svg"
class="hover:opacity-50"
>
<path
d="M24.8872 3.04499C23.9872 3.43499 23.0572 3.70498 22.0672 3.82499C23.0872 3.22498 23.8672 2.26499 24.2272 1.09499C23.2672 1.66499 22.2172 2.05499 21.1072 2.29499C20.2072 1.33499 18.9172 0.734985 17.5072 0.734985C14.7772 0.734985 12.5872 2.95499 12.5872 5.65499C12.5872 6.04499 12.6172 6.40498 12.7072 6.76498C8.62721 6.58498 5.02721 4.60498 2.59721 1.63499C0.857207 4.75498 2.80721 7.33499 4.09721 8.20499C3.31721 8.20499 2.53721 7.96499 1.87721 7.60499C1.87721 10.035 3.58721 12.045 5.80721 12.495C5.32721 12.645 4.24721 12.735 3.58721 12.585C4.21721 14.535 6.04721 15.975 8.17721 16.005C6.49721 17.325 4.03721 18.375 0.887207 18.045C3.07721 19.455 5.65721 20.265 8.44721 20.265C17.5072 20.265 22.4272 12.765 22.4272 6.28499C22.4272 6.07499 22.4272 5.86499 22.3972 5.65499C23.4172 4.90499 24.2572 4.03499 24.8872 3.04499Z"
fill="#151512"
/>
</svg>
</a>
</li>
<li class="pr-5">
<a href="https://github.com/vacp2p" target="_blank" rel="noopener noreferrer"
><svg
width="26"
height="25"
viewBox="0 0 26 25"
fill="none"
xmlns="http://www.w3.org/2000/svg"
class="hover:opacity-50"
>
<path
d="M12.8857 0.856567C6.26021 0.856567 0.915339 6.20154 0.950043 12.7951C0.9778 18.0687 4.43935 22.5427 9.21766 24.1227C9.81824 24.2327 10.0353 23.864 10.0336 23.5474C10.0321 23.2635 10.0177 22.5129 10.0065 21.5171C6.67274 22.238 5.95552 19.9163 5.95552 19.9163C5.40376 18.5369 4.61433 18.1698 4.61433 18.1698C3.51994 17.4296 4.69151 17.4444 4.69151 17.4444C5.89646 17.5291 6.53549 18.6751 6.53549 18.6751C7.61609 20.4989 9.35182 19.9727 10.0342 19.6665C10.1382 18.8951 10.4459 18.3689 10.7878 18.0702C8.12222 17.7684 5.31483 16.7443 5.29076 12.1708C5.2839 10.8672 5.74629 9.80152 6.50989 8.96619C6.3838 8.66445 5.96641 7.45009 6.61027 5.80766C6.61027 5.80766 7.61658 5.4866 9.9167 7.03094C10.8723 6.76636 11.8976 6.63408 12.9191 6.62962C13.9376 6.63556 14.9658 6.76636 15.9257 7.03242C18.2081 5.48809 19.2163 5.80914 19.2163 5.80914C19.8789 7.45306 19.4743 8.66594 19.3529 8.96767C20.1268 9.80301 20.5959 10.8687 20.6028 12.1723C20.6269 16.7577 17.8272 17.767 15.1558 18.0628C15.5882 18.4314 15.976 19.1597 15.9819 20.273C15.9903 21.8693 15.9821 23.1565 15.9841 23.5474C15.9858 23.867 16.2038 24.2386 16.8122 24.1212C21.5663 22.5397 24.9778 18.0672 24.95 12.7951C24.9153 6.20154 19.5142 0.856567 12.8857 0.856567Z"
fill="#151512"
/>
</svg>
</a>
</li>
<li>
<a
href="https://discord.gg/PQFdubGt6d"
target="_blank"
rel="noopener noreferrer"
><svg
width="25"
height="21"
viewBox="0 0 25 21"
fill="none"
xmlns="http://www.w3.org/2000/svg"
class="hover:opacity-50"
>
<path
d="M22.7861 9.04256C21.8482 5.74455 20.7799 4.04048 20.7627 4.00991C20.7017 3.93459 19.189 2.104 15.5271 0.75L15.0353 2.0764C16.7774 2.72057 18.0116 3.50643 18.6899 4.01419C16.6599 3.40408 14.2431 3.03041 12.1008 3.03041C9.95851 3.03041 7.53775 3.40408 5.50128 4.01419C6.18496 3.50648 7.42744 2.72057 9.17631 2.0764L8.69846 0.75C5.02238 2.104 3.49044 3.93459 3.42863 4.00991C3.41108 4.04048 2.32479 5.74455 1.35221 9.04256C0.414855 12.2208 0.0415214 16.7045 0.027872 16.8843C0.109225 17.0131 1.97891 20.25 7.12077 20.25L8.43406 18.3536C6.97595 17.964 5.58693 17.3357 4.31689 16.4832L5.10228 15.3069C7.15122 16.6822 9.54509 17.4092 12.0251 17.4092C14.5051 17.4092 16.9067 16.6822 18.9701 15.3069L19.7431 16.4832C18.4641 17.3357 17.0684 17.964 15.6062 18.3536L16.8995 20.25C22.0414 20.25 23.9452 17.0131 24.0279 16.8843C24.0161 16.7045 23.69 12.2208 22.7861 9.04256ZM8.79853 12.7392H7.39228L7.40468 10.3841H8.81093L8.79853 12.7392ZM16.7071 12.7392H15.3008L15.3132 10.3841H16.7195L16.7071 12.7392Z"
fill="#151512"
/>
</svg>
</a>
</li>
</ul>
</div>
<div
class="
overlay
container
max-w-screen-sm
w-full
hidden
sm:hidden
fixed
top-0
right-0
h-screen
bg-black bg-opacity-40
z-30
"
>
<nav
class="
nav-mobile
hidden
fixed
top-0
right-0
flex flex-col
justify-between
items-center
pt-14
px-12
pb-5
bg-white
w-9/12
h-3/4
z-40
"
>
<ul
class="
nav__list
flex flex-col flex-1
justify-between
items-center
container
box-content
w-32
h-auto
max-h-nav
text-xs
font-normal
"
>
<li class="hover:opacity-50">
<a class="nav__link" href="/#work">Work</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/#about">About</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/#join">Join VAC</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/research-log">Research log</a>
</li>
<li class="hover:opacity-50">
<a class="nav__link" href="/media">Media</a>
</li>
<li class="hover:opacity-50">
<a href="https://specs.vac.dev" target="_blank" rel="noopener noreferrer"
>Specs</a
>
</li>
<li class="hover:opacity-50">
<a href="https://forum.vac.dev/" target="_blank" rel="noopener noreferrer"
>Forum</a
>
</li>
</ul>
<ul class="social items-center flex mt-8">
<li class="pr-5">
<a href="https://twitter.com/vacp2p" target="_blank" rel="noopener noreferrer"
><svg
width="25"
height="21"
viewBox="0 0 25 21"
fill="none"
xmlns="http://www.w3.org/2000/svg"
class="hover:opacity-50"
>
<path
d="M24.8872 3.04499C23.9872 3.43499 23.0572 3.70498 22.0672 3.82499C23.0872 3.22498 23.8672 2.26499 24.2272 1.09499C23.2672 1.66499 22.2172 2.05499 21.1072 2.29499C20.2072 1.33499 18.9172 0.734985 17.5072 0.734985C14.7772 0.734985 12.5872 2.95499 12.5872 5.65499C12.5872 6.04499 12.6172 6.40498 12.7072 6.76498C8.62721 6.58498 5.02721 4.60498 2.59721 1.63499C0.857207 4.75498 2.80721 7.33499 4.09721 8.20499C3.31721 8.20499 2.53721 7.96499 1.87721 7.60499C1.87721 10.035 3.58721 12.045 5.80721 12.495C5.32721 12.645 4.24721 12.735 3.58721 12.585C4.21721 14.535 6.04721 15.975 8.17721 16.005C6.49721 17.325 4.03721 18.375 0.887207 18.045C3.07721 19.455 5.65721 20.265 8.44721 20.265C17.5072 20.265 22.4272 12.765 22.4272 6.28499C22.4272 6.07499 22.4272 5.86499 22.3972 5.65499C23.4172 4.90499 24.2572 4.03499 24.8872 3.04499Z"
fill="#151512"
/>
</svg>
</a>
</li>
<li class="pr-5">
<a href="https://github.com/vacp2p" target="_blank" rel="noopener noreferrer"
><svg
width="26"
height="25"
viewBox="0 0 26 25"
fill="none"
xmlns="http://www.w3.org/2000/svg"
class="hover:opacity-50"
>
<path
d="M12.8857 0.856567C6.26021 0.856567 0.915339 6.20154 0.950043 12.7951C0.9778 18.0687 4.43935 22.5427 9.21766 24.1227C9.81824 24.2327 10.0353 23.864 10.0336 23.5474C10.0321 23.2635 10.0177 22.5129 10.0065 21.5171C6.67274 22.238 5.95552 19.9163 5.95552 19.9163C5.40376 18.5369 4.61433 18.1698 4.61433 18.1698C3.51994 17.4296 4.69151 17.4444 4.69151 17.4444C5.89646 17.5291 6.53549 18.6751 6.53549 18.6751C7.61609 20.4989 9.35182 19.9727 10.0342 19.6665C10.1382 18.8951 10.4459 18.3689 10.7878 18.0702C8.12222 17.7684 5.31483 16.7443 5.29076 12.1708C5.2839 10.8672 5.74629 9.80152 6.50989 8.96619C6.3838 8.66445 5.96641 7.45009 6.61027 5.80766C6.61027 5.80766 7.61658 5.4866 9.9167 7.03094C10.8723 6.76636 11.8976 6.63408 12.9191 6.62962C13.9376 6.63556 14.9658 6.76636 15.9257 7.03242C18.2081 5.48809 19.2163 5.80914 19.2163 5.80914C19.8789 7.45306 19.4743 8.66594 19.3529 8.96767C20.1268 9.80301 20.5959 10.8687 20.6028 12.1723C20.6269 16.7577 17.8272 17.767 15.1558 18.0628C15.5882 18.4314 15.976 19.1597 15.9819 20.273C15.9903 21.8693 15.9821 23.1565 15.9841 23.5474C15.9858 23.867 16.2038 24.2386 16.8122 24.1212C21.5663 22.5397 24.9778 18.0672 24.95 12.7951C24.9153 6.20154 19.5142 0.856567 12.8857 0.856567Z"
fill="#151512"
/>
</svg>
</a>
</li>
<li>
<a
href="https://discord.gg/PQFdubGt6d"
target="_blank"
rel="noopener noreferrer"
><svg
width="25"
height="21"
viewBox="0 0 25 21"
fill="none"
xmlns="http://www.w3.org/2000/svg"
class="hover:opacity-50"
>
<path
d="M22.7861 9.04256C21.8482 5.74455 20.7799 4.04048 20.7627 4.00991C20.7017 3.93459 19.189 2.104 15.5271 0.75L15.0353 2.0764C16.7774 2.72057 18.0116 3.50643 18.6899 4.01419C16.6599 3.40408 14.2431 3.03041 12.1008 3.03041C9.95851 3.03041 7.53775 3.40408 5.50128 4.01419C6.18496 3.50648 7.42744 2.72057 9.17631 2.0764L8.69846 0.75C5.02238 2.104 3.49044 3.93459 3.42863 4.00991C3.41108 4.04048 2.32479 5.74455 1.35221 9.04256C0.414855 12.2208 0.0415214 16.7045 0.027872 16.8843C0.109225 17.0131 1.97891 20.25 7.12077 20.25L8.43406 18.3536C6.97595 17.964 5.58693 17.3357 4.31689 16.4832L5.10228 15.3069C7.15122 16.6822 9.54509 17.4092 12.0251 17.4092C14.5051 17.4092 16.9067 16.6822 18.9701 15.3069L19.7431 16.4832C18.4641 17.3357 17.0684 17.964 15.6062 18.3536L16.8995 20.25C22.0414 20.25 23.9452 17.0131 24.0279 16.8843C24.0161 16.7045 23.69 12.2208 22.7861 9.04256ZM8.79853 12.7392H7.39228L7.40468 10.3841H8.81093L8.79853 12.7392ZM16.7071 12.7392H15.3008L15.3132 10.3841H16.7195L16.7071 12.7392Z"
fill="#151512"
/>
</svg>
</a>
</li>
</ul>
</nav>
</div>
</div>
</div>
</header>
<main class="bg-white text-black flex flex-col"><section
class="
container
max-w-screen-xl
flex flex-col
sm:flex-row
pt-10
pb-0
md:pb-10
lg:pb-0
"
>
<div
class="
heading-block
w-full
sm:w-2/12
lg:w-3/12
flex
lg:justify-center
items-start
pb-3
sm:pb-0
"
>
<a class="link link--back" href="/research-log/">Back</a>
</div>
<div
class="info-block w-full sm:w-10/12 lg:w-9/12 pb-5 sm:pb-10 overflow-hidden"
>
<div class="post mb-10">
<h1 class="text-xl md:text-xxl mb-5 sm:max-w-md lg:max-w-2xl">
P2P Data Sync for Mobile
</h1>
<div>
<span class="text-s lg:text-base">
19 Jul 2019 • by
</span>
<a
href="/authors/oskarth"
class="text-s lg:text-base font-bold hover:underline"
>oskarth</a
>
</div>
</div>
<div class="post__content"><p>Together with decanus, I’ve been working on the problem of data sync lately.</p>
<p>In building p2p messaging systems, one problem you quickly come across is the problem of reliably transmitting data. If there’s no central server with high availability guarantees, you can’t meaningfully guarantee that data has been transmitted. One way of solving this problem is through a synchronization protocol.</p>
<p>There are many synchronization protocols out there and I won’t go into detail of how they differ with our approach here. Some common examples are Git and Bittorrent, but there are also projects like IPFS, Swarm, Dispersy, Matrix, Briar, SSB, etc.</p>
<h2 id="problem-motivation">Problem motivation</h2>
<p>Why do we want to do p2p sync for mobilephones in the first place? There are three components to that question. One is on the value of decentralization and peer-to-peer, the second is on why we’d want to reliably sync data at all, and finally why mobilephones and other resource restricted devices.</p>
<h3 id="why-p2p">Why p2p?</h3>
<p>For decentralization and p2p, there are both technical and social/philosophical reasons. Technically, having a user-run network means it can scale with the number of users. Data locality is also improved if you query data that’s close to you, similar to distributed CDNs. The throughput is also improved if there are more places to get data from.</p>
<p>Socially and philosophically, there are several ways to think about it. Open and decentralized networks also relate to the idea of open standards, i.e. compare the longevity of AOL with IRC or Bittorrent. One is run by a company and is shut down as soon as it stops being profitable, the others live on. Additionally increasingly control of data and infrastructure is becoming a liability. By having a network with no one in control, everyone is. It’s ultimately a form of democratization, more similar to organic social structures pre Big Internet companies. This leads to properties such as censorship resistance and coercion resistance, where we limit the impact a 3rd party might have a voluntary interaction between individuals or a group of people. Examples of this are plentiful in the world of Facebook, Youtube, Twitter and WeChat.</p>
<h3 id="why-reliably-sync-data">Why reliably sync data?</h3>
<p>At risk of stating the obvious, reliably syncing data is a requirement for many problem domains. You don’t get this by default in a p2p world, as it is unreliable with nodes permissionslessly join and leave the network. In some cases you can get away with only ephemeral data, but usually you want some kind of guarantees. This is a must for reliable group chat experience, for example, where messages are expected to arrive in a timely fashion and in some reasonable order. The same is true for messages there represent financial transactions, and so on.</p>
<h3 id="why-mobilephones">Why mobilephones?</h3>
<p>Most devices people use daily are mobile phones. It’s important to provide the same or at least similar guarantees to more traditional p2p nodes that might run on a desktop computer or computer. The alternative is to rely on gateways, which shares many of the drawbacks of centralized control and prone to censorship, control and surveillence.</p>
<p>More generally, resource restricted devices can differ in their capabilities. One example is smartphones, but others are: desktop, routers, Raspberry PIs, POS systems, and so on. The number and diversity of devices are exploding, and it’s useful to be able to leverage this for various types of infrastructure. The alternative is to centralize on big cloud providers, which also lends itself to lack of democratization and censorship, etc.</p>
<h2 id="minimal-requirements">Minimal Requirements</h2>
<p>For requirements or design goals for a solution, here’s what we came up with.</p>
<ol>
<li>
<p>MUST sync data reliably between devices. By reliably we mean having the ability to deal with messages being out of order, dropped, duplicated, or delayed.</p>
</li>
<li>
<p>MUST NOT rely on any centralized services for reliability. By centralized services we mean any single point of failure that isn’t one of the endpoint devices.</p>
</li>
<li>
<p>MUST allow for mobile-friendly usage. By mobile-friendly we mean devices that are resource restricted, mostly-offline and often changing network.</p>
</li>
<li>
<p>MAY use helper services in order to be more mobile-friendly. Examples of helper services are decentralized file storage solutions such as IPFS and Swarm. These help with availability and latency of data for mostly-offline devices.</p>
</li>
<li>
<p>MUST have the ability to provide casual consistency. By casual consistency we mean the commonly accepted definition in distributed systems literature. This means messages that are casually related can achieve a partial ordering.</p>
</li>
<li>
<p>MUST support ephemeral messages that don’t need replication. That is, allow for messages that don’t need to be reliabily transmitted but still needs to be transmitted between devices.</p>
</li>
<li>
<p>MUST allow for privacy-preserving messages and extreme data loss. By privacy-preserving we mean things such as exploding messages (self-destructing messages). By extreme data loss we mean the ability for two trusted devices to recover from a, deliberate or accidental, removal of data.</p>
</li>
<li>
<p>MUST be agnostic to whatever transport it is running on. It should not rely on specific semantics of the transport it is running on, nor be tightly coupled with it. This means a transport can be swapped out without loss of reliability between devices.</p>
</li>
</ol>
<h2 id="mvds---a-minimium-viable-version">MVDS - a minimium viable version</h2>
<p>The first minimum viable version is in an alpha stage, and it has a <a href="https://github.com/vacp2p/specs/blob/master/mvds.md">specification</a>, <a href="https://github.com/vacp2p/mvds">implementation</a> and we have deployed it in a <a href="https://github.com/status-im/status-console-client">console client</a> for end to end functionality. It’s heavily inspired by <a href="https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md">Bramble Sync Protocol</a>.</p>
<p>The spec is fairly minimal. You have nodes that exchange records over some secure transport. These records are of different types, such as <code class="language-plaintext highlighter-rouge">OFFER</code>, <code class="language-plaintext highlighter-rouge">MESSAGE</code>, <code class="language-plaintext highlighter-rouge">REQUEST</code>, and <code class="language-plaintext highlighter-rouge">ACK</code>. A peer keep tracks of the state of message for each node it is interacting with. There’s also logic for message retransmission with exponential delay. The positive ACK and retransmission model is quite similar to how TCP is designed.</p>
<p>There are two different modes of syncing, interactive and batch mode. See sequence diagrams below.</p>
<p>Interactive mode:
<img src="/assets/img/mvds_interactive.png" /></p>
<p>Batch mode:
<img src="/assets/img/mvds_batch.png" /></p>
<p>Which mode should you choose? It’s a tradeoff of latency and bandwidth. If you want to minimize latency, batch mode is better. If you care about preserving bandwidth interactive mode is better. The choice is up to each node.</p>
<h3 id="basic-simulation">Basic simulation</h3>
<p>Initial ad hoc bandwidth and latency testing shows some issues with a naive approach. Running with the <a href="https://github.com/vacp2p/mvds/">default simulation settings</a>:</p>
<ul>
<li>communicating nodes: 2</li>
<li>nodes using interactive mode: 2</li>
<li>interval between messages: 5s</li>
<li>time node is offine: 90%</li>
<li>nodes each node is sharing with: 2</li>
</ul>
<p>we notice a <a href="https://notes.status.im/7QYa4b6bTH2wMk3HfAaU0w#">huge overhead</a>. More specifically, we see a ~5 minute latency overhead and a bandwidth multiplier of x100-1000, i.e. 2-3 orders of magnitude just for receiving a message with interactive mode, without acks.</p>
<p>Now, that seems terrible. A moment of reflection will reveal why that is. If each node is offline uniformly 90% of the time, that means that each record will be lost 90% of the time. Since interactive mode requires offer, request, payload (and then ack), that’s three links just for Bob to receive the actual message.</p>
<p>Each failed attempt implies another retransmission. That means we have <code class="language-plaintext highlighter-rouge">(1/0.1)^3 = 1000</code> expected overhead to receive a message in interactive mode. The latency follows naturally from that, with the retransmission logic.</p>
<h3 id="mostly-offline-devices">Mostly-offline devices</h3>
<p>The problem above hints at the requirements 3 and 4 above. While we did get reliable syncing (requirement 1), it came at a big cost.</p>
<p>There are a few ways of getting around this issue. One is having a <em>store and forward</em> model, where some intermediary node picks up (encrypted) messages and forwards them to the recipient. This is what we have in production right now at Status.</p>
<p>Another, arguably more pure and robust, way is having a <em>remote log</em>, where the actual data is spread over some decentralized storage layer, and you have a mutable reference to find the latest messages, similar to DNS.</p>
<p>What they both have in common is that they act as a sort of highly-available cache to smooth over the non-overlapping connection windows between two endpoints. Neither of them are <em>required</em> to get reliable data transmission.</p>
<h3 id="basic-calculations-for-bandwidth-multiplier">Basic calculations for bandwidth multiplier</h3>
<p>While we do want better simulations, and this is a work in progress, we can also look at the above scenarios using some basic calculations. This allows us to build a better intuition and reason about the problem without having to write code. Let’s start with some assumptions:</p>
<ul>
<li>two nodes exchanging a single message in batch mode</li>
<li>10% uniformly random uptime for each node</li>
<li>in HA cache case, 100% uptime of a piece of infrastructure C</li>
<li>retransmission every epoch (with constant or exponential backoff)</li>
<li>only looking at average (p50) case</li>
</ul>
<h4 id="first-case-no-helper-services">First case, no helper services</h4>
<p>A sends a message to B, and B acks it.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>A message -&gt; B (10% chance of arrival)
A &lt;- ack B (10% chance of arrival)
</code></pre></div></div>
<p>With a constant backoff, A will send messages at epoch <code class="language-plaintext highlighter-rouge">1, 2, 3, ...</code>. With exponential backoff and a multiplier of 2, this would be <code class="language-plaintext highlighter-rouge">1, 2, 4, 8, ...</code>. Let’s assume constant backoff for now, as this is what will influence the success rate and thus the bandwidth multiplier.</p>
<p>There’s a difference between <em>time to receive</em> and <em>time to stop sending</em>. Assuming each send attempt is independent, it takes on average 10 epochs for A’s message to arrive with B. Furthermore:</p>
<ol>
<li>A will send messages until it receives an ACK.</li>
<li>B will send ACK if it receives a message.</li>
</ol>
<p>To get an average of one ack through, A needs to send 100 messages, and B send on average 10 acks. That’s a multiplier of roughly a 100. That’s roughly what we saw with the simulation above for receiving a message in interactive mode.</p>
<h4 id="second-case-high-availability-caching-layer">Second case, high-availability caching layer</h4>
<p>Let’s introduce a helper node or piece of infrastructure, C. Whenever A or B sends a message, it also sends it to C. Whenever A or B comes online, it queries for messages with C.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>A message -&gt; B (10% chance of arrival)
A message -&gt; C (100% chance of arrival)
B &lt;- req/res -&gt; C (100% chance of arrival)
A &lt;- ack B (10% chance of arrival)
C &lt;- ack B (100% chance of arrival)
A &lt;- req/res -&gt; C (100% chance of arrival)
</code></pre></div></div>
<p>What’s the probability that A’s messages will arrive at B? Directly, it’s still 10%. But we can assume it’s 100% that C picks up the message. (Giving C a 90% chance success rate doesn’t materially change the numbers).</p>
<p>B will pick up A’s message from C after an average of 10 epochs. Then B will send ack to A, which will also be picked up by C 100% of the time. Once A comes online again, it’ll query C and receive B’s ack.</p>
<p>Assuming we use exponential backoff with a multiplier of 2, A will send a message directly to B at epoch <code class="language-plaintext highlighter-rouge">1, 2, 4, 8</code> (assuming it is online). At this point, epoch <code class="language-plaintext highlighter-rouge">10</code>, B will be online in the average case. These direct sends will likely fail, but B will pick the message up from C and send one ack, both directly to A and to be picked up by C. Once A comes online, it’ll query C and receive the ack from B, which means it won’t do any more retransmits.</p>
<p>How many messages have been sent? Not counting interactions with C, A sends 4 (at most) and B 1. Depending on if the interaction with C is direct or indirect (i.e. multicast), the factor for interaction with C will be ~2. This means the total bandwidth multiplier is likely to be <code class="language-plaintext highlighter-rouge">&lt;10</code>, which is a lot more acceptable.</p>
<p>Since the syncing semantics are end-to-end, this is without relying on the reliablity of C.</p>
<h4 id="caveat">Caveat</h4>
<p>Note that both of these are probabilistic argument. They are also based on heuristics. More formal analysis would be desirable, as well as better simulations to experimentally verify them. In fact, the calculations could very well be wrong!</p>
<h2 id="future-work">Future work</h2>
<p>There are many enhancements that can be made and are desirable. Let’s outline a few.</p>
<ol>
<li>
<p>Data sync clients. Examples of actual usage of data sync, with more interesting domain semantics. This also includes usage of sequence numbers and DAGs to know what content is missing and ought to be synced.</p>
</li>
<li>
<p>Remote log. As alluded to above, this is necessary. It needs a more clear specification and solid proof of concepts.</p>
</li>
<li>
<p>More efficient ways of syncing with large number of nodes. When the number of nodes goes up, the algorithmic complexity doesn’t look great. This also touches on things such as ambient content discovery.</p>
</li>
<li>
<p>More robust simulations and real-world deployments. Exisiting simulation is ad hoc, and there are many improvements that can be made to gain more confidence and identify issues. Additionally, better formal analysis.</p>
</li>
<li>
<p>Example usage over multiple transports. Including things like sneakernet and meshnets. The described protocol is designed to work over unstructured, structured and private p2p networks. In some cases it can leverage differences in topology, such as multicast, or direct connections.</p>
</li>
</ol>
</div>
</div>
</section>
</main>
</div>
<footer class="footer bg-black flex flex-shrink-0 justify-center">
<div
class="
container
max-w-screen-xl
flex
sl:justify-between
lm:justify-start
p-5
pb-10
md:px-12 md:pt-5
lg:pt-10
"
>
<div class="logo mr-10 sm:mr-0 sm:w-2/12 lg:w-3/12">
<a href="/"
><img
src="/assets/img/logo.png"
alt="Vac logo"
class="w-9 h-11"
/></a>
</div>
<div
class="flex flex-col xm:flex-row xm:justify-between sm:w-10/12 lg:w-9/12"
>
<p
class="
hidden
ml:inline-block ml:mr-10
w-52
text-base text-white
opacity-75
lm:mr-32
"
>
VAC researches peer-to-peer, private, censorship resistant communication
</p>
<nav class="flex max-w-xs mr-0 xm:mr-5 l:mr-32 mb-5 sm:mb-0">
<div class="flex">
<div class="flex flex-col mr-5 sm:mr-10 sl:mr-14">
<p class="text-base text-white mb-5 lg:mb-4">Research</p>
<ul>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://status.im/" target="_blank" rel="noopener noreferrer"
>Log</a
>
</li>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://forum.vac.dev/" target="_blank" rel="noopener noreferrer"
>Forum</a
>
</li>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://status.im/" target="_blank" rel="noopener noreferrer"
>Media</a
>
</li>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://jobs.status.im/?search=Vac" target="_blank" rel="noopener noreferrer"
>Careers</a
>
</li>
</ul>
</div>
<div class="flex flex-col sl:mr-14">
<p class="text-base text-white mb-5 lg:mb-4 mr-5">Socials</p>
<ul>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://twitter.com/vacp2p" target="_blank" rel="noopener noreferrer"
>Twitter</a
>
</li>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://discord.gg/PQFdubGt6d" target="_blank" rel="noopener noreferrer"
>Discord</a
>
</li>
<li class="text-xxs lg:text-base text-white opacity-75 hover:opacity-50 mb-5">
<a href="https://t.me/vacp2p" target="_blank" rel="noopener noreferrer"
>Telegram</a
>
</li>
</ul>
</div>
</div></nav>
<div class="flex flex-col w-52">
<h3 class="text-base text-white mb-5">Signup for updates</h3>
<form action="" class="footer__form">
<div class="flex items-center w-full">
<input
class="
text-xs text-white
w-full
bg-black
border-b border-white
rounded-none
mr-2
focus:outline-none
placeholder-white placeholder-opacity-50
"
type="email"
placeholder="your email"
required
/>
<button
class="
h-10
w-10
bg-arrowWhite bg-auto bg-no-repeat bg-left
focus:outline-none
hover:opacity-50
"
type="submit"
></button>
</div>
</form>
<p
class="footer__confirm text-base italic text-white opacity-75 hidden"
>
You signed up! Check your e-mail
</p>
</div>
</div>
</div>
</footer>
<script src="/assets/js/main.js"></script>
<script src="/assets/js/smooth-scroll.js"></script>
</body>
</html>
Reference in New Issue Copy Permalink