Expand description
Wire types for the ripsync↔ripsync remote-sync protocol.
Both peers are ripsync; the protocol is not wire-compatible with real
rsync. Control messages are bincode-serialized inside length-prefixed frames
(see super::transport). The flow is receiver-driven lock-step: the
side that holds the source (“sender”) streams its file list, then becomes
purely reactive — it answers one Request with one Data response at a
time. The side that holds the destination (“receiver”) drives: it requests
the content it needs, applies each response, and finally sends Msg::Finished
to terminate. Because exactly one side is ever waiting to read while the other
computes-then-writes, the single duplex stream cannot deadlock.
Structs§
- Init
- The first framed message the initiator sends after the raw handshake: it tells the responder which role to play and over which root.
- NetEntry
- One entry in the sender’s file list.
- NetOptions
- Options that affect how the transfer is performed, negotiated once.
Enums§
- Data
- Sender → receiver: the response to a
Request. - Msg
- Every framed message on the wire.
- NetKind
- What a listed entry is.
- Request
- Receiver → sender: the content the receiver needs for one file.
- Role
- Which direction the local (initiating) side asked for.
Constants§
- MAGIC
- Magic prefix sent raw (unframed) at the very start of a connection.
- PROTO_
VERSION - Protocol version. Bump on any incompatible wire change.