akwizgran created page: BSP

akwizgran
2015-03-26 19:33:30 +00:00
parent e815e51caa
commit dcb0dbb68f

@@ -1,4 +1,4 @@
BSP is an application layer data synchronisation protocol for delay-tolerant networks. It can operate over any transport that can deliver a simplex stream of bytes from a sender to a recipient on a best-effort basis. BSP does not ensure the confidentiality, authenticity or integrity of the transported streams; that is the responsibility of a transport layer security protocol such as [BTP](BTP).
BSP is an application layer data synchronisation protocol for delay-tolerant networks. It can operate over any transport that can deliver a simplex stream of bytes from a sender to a recipient on a best-effort basis, meaning that streams may be delayed, lost, reordered or duplicated by the transport layer. BSP does not ensure the confidentiality, authenticity or integrity of streams; that is the responsibility of a transport layer security protocol such as [BTP](BTP).
BSP synchronises data between two devices referred to as the local and remote peers. The data to be synchronised consists of messages posted to channels. A message is simply a sequence of bytes, and a channel is simply a set of messages.
@@ -28,9 +28,7 @@ A block accompanied by its message and block headers is called a portable block.
### Records
The local and remote peers synchronise data by sending simplex streams of bytes to each other. Streams are delivered by the transport layer on a best-effort basis: they may be delayed, lost, reordered and duplicated by the transport layer.
A stream consists of a series of records, each of which starts with a record header with the following format:
The local and remote peers synchronise data by sending simplex streams of bytes to each other. A stream consists of a series of records, each of which starts with a record header with the following format:
* Bits 0-7: Protocol version
* Bits 8-15: Record type
@@ -48,7 +46,7 @@ The current version of the protocol is 1, with five record types:
**3: ACK** - The payload consists of one or more block identifiers. This record informs the recipient that the sender holds the listed blocks.
**4. RESET** - The payload consists of a channel identifier. This record asks the recipient to discard any information about which blocks the sender holds in the given channel.
**4. RESET** - The payload is empty. This record asks the recipient to discard any information about which blocks the sender holds.
The local peer is said to hold a block if it is storing the block and sharing it with the remote peer. If the local peer is storing a block but not sharing it with the remote peer, the local peer acts as though it were not storing the block.
@@ -92,4 +90,4 @@ Whenever the local peer offers or sends a block it updates the block's send coun
### Resetting
If the local peer crashes shortly after receiving and acknowledging a block, the local peer may fail to store the block, but the remote peer may receive the acknowledgement and no longer offer or send the block. Reset records are used to recover from this situation. If the local peer detects that it has crashed, it may send a reset record to reset the remote peer's knowledge of which blocks the local peer holds.
If the local peer crashes while synchronising with the remote peer, the local peer may fail to store blocks that it has already acknowledged. (This can happen even if the local peer waits for the blocks to be stored before acknowledging them, as there are many layers of buffers between the application and the storage medium.) The remote peer will no longer offer or send blocks that the local peer has acknowledged, so the peers may remain out of sync indefinitely. If the local peer detects that it has crashed, it should send a reset record to reset the remote peer's knowledge of which blocks the local peer holds.