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

akwizgran created page: Roadmap

akwizgran
2015-12-04 17:41:09 +00:00
parent 01cc8ea03c
commit ceaf0b6f97
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
BSP.markdown → BSP.md

@@ -94,7 +94,7 @@ The local peer stores the following synchronisation state for each block it hold
* 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 and initialised to 0
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 identifiers if the maximum length is reached.
The local peer also stores a list of block 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 replace the oldest entry in the list if the maximum length is reached.
### Interactive mode and batch mode
@@ -120,8 +120,8 @@ A block is not offered or sent until its send time is reached.
### Retransmission
Whenever the local peer offers or sends a block it increased the block's send count and send time. BSP does not specify how the send time should be increased, except that the amount by which it is increased should increase exponentially with the send count. The local peer may increase the send time based on measurements of the transport's round-trip time and round-trip time variance, as in TCP, or it may use any other method.
Whenever the local peer offers or sends a block it increases the block's send count and send time. BSP does not specify how the send time should be increased, except that the amount by which it is increased should increase exponentially with the send count. The local peer may increase the send time based on measurements of the transport's round-trip time and round-trip time variance, as in TCP, or it may use any other method.
### Resetting
If the local peer crashes, it 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 physical 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 information about which blocks the local peer holds.
If the local peer crashes, it may fail to store blocks that it has already acknowledged. (This can happen even if the local peer stores the blocks before acknowledging them, as there are many layers of buffers between the application and the physical 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 information about which blocks the local peer holds.