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 16:40:31 +00:00
parent 550a4fda83
commit e815e51caa
1 changed files with 9 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
BSP.markdown

@@ -60,9 +60,9 @@ The local peer stores the following synchronisation state for each block it hold
* Ack flag - Set to 1 if the local peer needs to acknowledge 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 * 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 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 * 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 and 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. The local peer also stores a list of message identifiers that have been offered by the remote peer and not yet acknowledged or requested by the local peer. The length of this list should be bounded, and the local peer should discard the oldest items if the maximum length is reached.
### Interactive mode and batch mode ### Interactive mode and batch mode
@@ -84,5 +84,12 @@ In batch mode, blocks are sent without being offered. The sender does the follow
* Send any blocks requested by the recipient * Send any blocks requested by the recipient
* Send any blocks that the sender does not know whether the recipient holds * Send any blocks that the sender does not know whether the recipient holds
A block is not offered or sent until its send time is reached.
### Retransmission ### Retransmission
Whenever the local peer offers or sends a block it updates the block's send count and send time. BSP does not specify how the send time should be updated, except that the updates should increase exponentially with the send count. The local peer may base the updates on measurements of the transport's round-trip time and round-trip time variance, as in TCP, or it may use any other method. A block may be offered or sent over many different transports, and the method of updating the send time should take this into account.
### 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.