mirror of https://github.com/vacp2p/research.git
97 lines
3.4 KiB
Plaintext
97 lines
3.4 KiB
Plaintext
# Moving over notes to make sync.py less noisy
|
|
|
|
## TODO: Sync modes, interactive (+bw -latency) and batch (v.v.)
|
|
|
|
# Need to encode logic for actions taken at given time,
|
|
# respect send_time etc,
|
|
# WRT offer messages and so on
|
|
|
|
# Batch mode first (less coordination):
|
|
# - **Acknowledge** any messages **sent** by the peer that the device has not yet
|
|
# acknowledged
|
|
# - **Acknowledge** any messages **offered** by the peer that the device holds,
|
|
# and has not yet acknowledged
|
|
# - **Request** any messages **offered** by the peer that the device does not
|
|
# hold, and has not yet requested
|
|
# - **Send** any messages that the device is **sharing** with the peer, that have
|
|
# been **requested** by the peer, and that have reached their send times
|
|
# - **Send** any messages that the device is **sharing** with the peer, and does
|
|
# not know whether the peer holds, and that have reached their send times
|
|
|
|
# each tick
|
|
# SEND messages device is SHARING with the peer, doesn't know if peer holds,
|
|
# and reached send time
|
|
# What mean by sharing
|
|
|
|
# Member of a group:
|
|
# Two peers sync group message they share group
|
|
# Membership and sharing dynamic
|
|
|
|
# How do we de determine if two peers synchronize a
|
|
# specific group's messages with eachother?
|
|
|
|
# For any given (data) group, a device can decide
|
|
# if they want to share or not with a peer.
|
|
|
|
# TODO: ACK should also be share policy
|
|
# XXX: Encode offline mostly
|
|
|
|
# XXX: How does B look at the message?
|
|
|
|
# XXX: If A,B reliability 0.1 and C 0.9
|
|
# How does that actually realistically look?
|
|
|
|
# Need to encode the other actions and offer etc
|
|
# Exponential backoff too probably
|
|
|
|
# Then C can offer messages to B, e.g.
|
|
|
|
# How viz message graph?
|
|
# XXX: How will C receive the message from A to B?
|
|
# TODO: Requires offering to B, e.g.
|
|
# Or B requesting it
|
|
|
|
# Why is A sending same message to C over again
|
|
# and again, with reliability = 1,1?
|
|
# C no op? it acks but A ignores it?
|
|
# Duh, C sends but A doesn't see it...
|
|
|
|
# TODO: When A comes online, whenever that is
|
|
# It needs to requests messages
|
|
# Aka ask C (or whomever) for messages
|
|
# How?
|
|
# - **Request** any messages **offered** by the peer that the device does not
|
|
# But how would it know to offer messages?
|
|
# It could play nice and offer all messages it has to C, but if C has all
|
|
# There needs to be some way for C to go for it, unless A is going to over-offer with bloom filter or so
|
|
# Look into this a bit more, naive way is signal
|
|
|
|
run(20)
|
|
|
|
# XXX: What happens if ACK fails? Offer back? Lol.
|
|
# See no mention of re-send acks
|
|
|
|
# Actually C should have other message right? Oh no can't, need 4th node
|
|
# Voila, introduce 4th node only semi conected and awareness
|
|
# Even if never online or never both connected to same super node!
|
|
|
|
# It is even the case that message from A 4ea1 then B 9e70
|
|
# So A holds data from B without knowing B has it! Propagated through C
|
|
# And C got it from D!
|
|
# But if A and B online same time then this data is available
|
|
|
|
# One problem is that you don't know REQ/etc state of data. Chill and OK?
|
|
|
|
# What do we want to measure here? In terms of reliability of perf etc
|
|
|
|
# Probably want to clean up this file a bit as well
|
|
# Different basic scenarios with assumptions?
|
|
# Message propagation? Not sure
|
|
|
|
# Privacy and sharing implications
|
|
# Exact diff with peer connected to and sharing
|
|
# If you introduce new party for sharing data, well they know you connecting
|
|
# What does this imply exactly? Esp if network topology is certain way
|
|
|
|
# Write down specific questions/concerns here
|