Kaladaran/briar
0
0
Fork 0
mirror of https://code.briarproject.org/briar/briar.git synced 2026-03-05 21:18:17 +01:00
Code Issues Projects Releases Wiki Activity

akwizgran created page: BSP

akwizgran
2015-03-24 12:18:05 +00:00
parent 8750e147b7
commit 71de845639
1 changed files with 25 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
BSP.markdown

@@ -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 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. 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 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.
@@ -14,14 +14,36 @@ Each channel has a unique identifier hash_len bytes long. This identifier is sup
### Message format
Each message consists of one or more blocks, block_len bytes long, except the last, which may be shorter. The blocks form the leaves of a binary hash tree. Each parent node consists of the concatenated hashes of its children. If the number of blocks is not a power of two, some parent nodes will only have one child.
Each message consists of one or more blocks. Each block is block_len bytes long, except the last, which may be shorter. (We require that block_len <= 2^15.) The blocks form the leaves of a binary hash tree. Each parent node consists of the concatenated hashes of its children. If the number of blocks is not a power of two, some parent nodes will only have one child.
The message's unique identifier is calculated by hashing a message header concatenated with the root hash of the tree. The message header consists of the channel identifier, a timestamp, the message length and the message type.
The timestamp is a 64-bit integer representing seconds since the Unix epoch. (All integers in BSP are big-endian and signed.) The message length is a 64-bit integer representing the length of the message in bytes. The message type is a single byte that is supplied by the application and is not interpreted by BSP.
The timestamp is a 64-bit integer representing seconds since the Unix epoch. (All integers in BSP are big-endian.) The message length is a 64-bit integer representing the length of the message in bytes. The message type is a single byte that is supplied by the application and is not interpreted by BSP.
Each block also has a unique identifier, which is calculated by hashing the message header concatenated with a block header and the hash of the block itself. The block header consists of the block number and a list of hashes called the path.
The block number is a 64-bit integer starting from zero for the first block of the message. The path contains the hashes of the siblings of the block's ancestors in the hash tree. If the number of blocks is not a power of two, some ancestors may not have siblings. The positions of any nonexistent siblings can be calculated from the message length and the block number.
A block accompanied by its message and block headers is called a portable block. A portable block is valid if the message and block headers are consistent with each other and with the length of the block. A valid portable block contains all the information needed to calculate the message identifier. Any valid portable blocks that produce the same message identifier are guaranteed to be consistent with each other. This makes it possible to synchronise messages a block at a time.
### 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, meaning that streams may be delayed, lost or reordered.
Each stream consists of one or more records of any type in any order. Each record starts with a record header with the following format:
* Bits 0-7: Protocol version
* Bits 8-15: Record type
* Bits 16-31: Payload length in bytes as a 16-bit integer
If the recipient does not recognise the protocol version or record type, the recipient skips to the next record in the stream.
The current version of BSP is version 1, with four record types:
Type 0: **OFFER** - The payload consists of one or more block identifiers. An offer informs the recipient that the sender holds the listed blocks and wishes to know whether to send them.
Type 1: **REQUEST** - The payload consists of one or more block identifiers. A request asks the recipient to send the listed blocks.
Type 2: **BLOCK** - The payload consists of a portable block.
Type 3: **ACK** - The payload consists of one or more block identifiers. An ack informs the recipient that the sender holds the listed blocks.