acid-info/vac.dev
1
0
Fork 0
mirror of https://github.com/acid-info/vac.dev.git synced 2025-02-22 08:38:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

small tweaks

Browse Source
This commit is contained in:
Oskar Thoren 2019-10-02 15:00:23 +08:00
parent c66fda4dc6
commit 0cc8130f45
No known key found for this signature in database
GPG Key ID: B2ECCFD3BC2EF77E
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
_posts/2019-10-01-remote-log.md
View File

@ -13,7 +13,7 @@ image: /assets/img/remote-log.png
A big problem when doing end-to-end data sync between mobile nodes is that most devices are offline most of the time. With a naive approach, you quickly run into issues of 'ping-pong' behavior, where messages have to be constantly retransmitted. We saw some basic calculations of what this bandwidth multiplier looks like in a [previous post](https://vac.dev/p2p-data-sync-for-mobile).
While you could do some background processing, this is really battery-draining, and on iOS these capabilities are limited. A better approach instead is to loosen the constraint that two nodes need to be online at the same time. How do we do this? There are two main approaches, one is the **store and forward model**, and the other is a **remote log**.
While you could do some background processing, this is really battery-draining, and on iOS these capabilities are limited. A better approach instead is to loosen the constraint that two nodes need to be online at the same time. How do we do this? There are two main approaches, one is the *store and forward model*, and the other is a *remote log*.
In the *store and forward* model, we use an intermediate node that forward messages on behalf of the recipient. In the *remote log* model, you instead replicate the data onto some decentralized storage, and have a mutable reference to the latest state, similar to DNS. While both work, the latter is somewhat more elegant and "pure", as it has less strict requirements of an individual node's uptime. Both act as a highly-available cache to smoothen over non-overlapping connection windows between endpoints.
@ -31,7 +31,7 @@ In this post we are going to describe how such a remote log schema could work. S
A remote log is a replication of a local log. This means a node can read data from a node that is offline.
The spec is in an early draft stage and can be found [here](https://github.com/vacp2p/specs/pull/16). A very basic [spike](https://en.wikipedia.org/wiki/Spike_(software_development))/proof-of-concept can be found [here](https://github.com/vacp2p/research/tree/master/remote_log). The rest of this post follows the current spec closely.
The spec is in an early draft stage and can be found [here](https://github.com/vacp2p/specs/pull/16). A very basic [spike](https://en.wikipedia.org/wiki/Spike_(software_development)) / proof-of-concept can be found [here](https://github.com/vacp2p/research/tree/master/remote_log).
### Definitions