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-26 13:59:04 +00:00
parent 71de845639
commit 550a4fda83
1 changed files with 50 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
BSP.markdown

@@ -22,28 +22,67 @@ The timestamp is a 64-bit integer representing seconds since the Unix epoch. (Al
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. 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. The block number is a 64-bit integer starting from zero for the first block of the message. The path consists of 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. A block accompanied by its message and block headers is called a portable block. A portable block is valid if the message length, block number, path and block length are consistent with each other. 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.
### Records ### 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. 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.
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: 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 0-7: Protocol version
* Bits 8-15: Record type * Bits 8-15: Record type
* Bits 16-31: Payload length in bytes as a 16-bit integer * Bits 16-31: Length of the payload 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. A stream may contain records of any type in any order. 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: The current version of the protocol is 1, with five 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. **0: OFFER** - The payload consists of one or more block identifiers. This record 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. **1: REQUEST** - The payload consists of one or more block identifiers. This record asks the recipient to send the listed blocks.
Type 2: **BLOCK** - The payload consists of a portable block. **2: DATA** - The payload consists of a portable block.
**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.
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.
### Synchronisation state
The local peer stores the following synchronisation state for each block it holds:
* Hold flag - Set to 1 if the remote peer is known to hold the block, otherwise 0
* Ack flag - Set to 1 if the local peer needs to acknowledge the block, otherwise 0
* Request flag - Set to 1 if the remote peer has requested the block since it was last sent, otherwise 0
* Send count - The number of times the block has been offered or sent to the remote peer
* Send time - A timestamp indicating when the block can next be offered or sent to the remote peer; measured in seconds since the Unix epoch, initialised to 0
The local peer also keeps a list of message identifiers that have been offered by the remote peer and not yet acknowledged or requested. The length of this list should be bounded, and the local peer should discard the oldest items when the maximum length is reached.
### Interactive mode and batch mode
The sender of each stream decides whether the stream will use interactive mode or batch mode. Interactive mode uses less bandwidth than batch mode, but needs two round-trips for synchronisation, whereas batch mode needs one. The sender's choice may depend on prior knowledge or measurements of the underlying transport. BSP does not specify how to decide which mode to use - the local and remote peers may use different criteria, and peers may change their criteria at any time.
In interactive mode, blocks are offered before being sent. The sender does the following (in any order):
* Acknowledge any blocks sent by the recipient
* Acknowledge any blocks offered by the recipient that the sender holds
* Request any blocks offered by the recipient that the sender does not hold
* Offer any blocks that the sender does not know whether the recipient holds
* Send any blocks requested by the recipient
In batch mode, blocks are sent without being offered. The sender does the following (in any order):
* Acknowledge any blocks sent by the recipient
* Acknowledge any blocks offered by the recipient that the sender holds
* Request any blocks offered by the recipient that the sender does not hold
* Send any blocks requested by the recipient
* Send any blocks that the sender does not know whether the recipient holds
### Retransmission
Type 3: **ACK** - The payload consists of one or more block identifiers. An ack informs the recipient that the sender holds the listed blocks.