| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
When keepalive says ready and we didn't have taht on record before,
the peer is queued for sync. Hello and hello reply don't do this
because the handshake already queues a sync.
|
| |
|
|
|
|
|
|
|
|
| |
Ready nodes will leave the first message to the pear that isn't ready.
Hello and hello reply now carry ready, so readiness is known from the
very first contact, before any sync. Together with the sync messages
and keepalives, reports_ready is always current.
After epoch switch, pings go to everyone except ready members already
on the new epoch, these learn from the lagging peer's opening.
|
| | |
|
| |
|
|
|
| |
The handshake resets the session anyway, and the sender's reply timeout
resends what still matters.
|
| |
|
|
|
| |
Instead of arbitrarily limiting the number to 16, allow filling
keepalive messages as long as they don't cause mycelium to chunk it.
|
| |
|
|
| |
This allows changing sources without the fixed 30 s stall duration.
|
| |
|
|
|
|
|
| |
Add ready and syncs_with_you flags as well as actual heads, so the peer
- ready: same meaning as in the sync message
- syncs_with_you: sender counts recipient as member and in same epoch
- heads: allows to tell who's behind or if both sides have changes
|
| | |
|
| | |
|
| |
|
|
| |
SyncSession holds all fields that get reset by reset_sync()
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
When an sync messages arrives and automerge has nothing to say about it,
then no reply is generated. With c9279e4 it was assumed that every sync
message gets an answer, so missing replies caused unnecessary resends.
Now a reply is only awaited if the peer's last reported heads differ
from ours. If the peer's heads become equal through a third peer without
replying, the waiting will also abort if a ping or pong showss the same
heads digest on both sides.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
