Kaladaran/briar
0
0
Fork 0
mirror of https://code.briarproject.org/briar/briar.git synced 2026-02-22 23:59:54 +01:00
Code Issues Projects Releases Wiki Activity

akwizgran deleted page: TransportApp

akwizgran
2015-04-20 09:23:32 +00:00
parent 013d810083
commit caefadac68
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
BSP.markdown

@@ -2,7 +2,7 @@ BSP is an application layer data synchronisation protocol for delay-tolerant net
BSP synchronises data between two devices referred to as the local and remote peers. The data to be synchronised consists of messages, which are organised into channels. From BSP's point of view, a message is simply a sequence of bytes and a channel is simply a set of messages. A message created by the local peer is called a local message, while a message synchronised from the remote peer is called a remote message.
Each channel on the local peer belongs to an application, which is responsible for deciding which messages are valid (the validity policy), which remote messages should be stored on the local peer (the storage policy), and which local messages should be shared with the remote peer (the sharing policy).
Each channel on the local peer belongs to a client, which is responsible for deciding which messages are valid (the validity policy), which remote messages should be stored on the local peer (the storage policy), and which local messages should be shared with the remote peer (the sharing policy).
### Notation
@@ -16,16 +16,16 @@ BSP uses a cryptographic hash function, H(m), with an output length of HASH_LEN
### Channel identifiers
Each channel has a unique identifier HASH_LEN bytes long. This identifier is supplied by the application and is not interpreted by BSP, but to prevent collisions between applications, BSP specifies how channel identifiers may be generated. The channel identifier may be random:
Each channel has a unique identifier HASH_LEN bytes long. This identifier is supplied by the client and is not interpreted by BSP, but to prevent collisions between clients, BSP specifies how channel identifiers may be generated. The channel identifier may be random:
* `channel_id = R(HASH_LEN)`
Alternatively, the channel identifier may be the hash of a random application identifier HASH_LEN bytes long and an application data structure describing the channel:
Alternatively, the channel identifier may be the hash of a random client identifier HASH_LEN bytes long and a client data structure describing the channel:
* `app_id = R(HASH_LEN)`
* `channel_id = HASH("CHANNEL_ID", app_id, app_data_structure)`
* `client_id = R(HASH_LEN)`
* `channel_id = HASH("CHANNEL_ID", client_id, client_data_structure)`
Including the application identifier in the hash prevents collisions between applications with similar data structures.
Including the client identifier in the hash prevents collisions between clients that use similar data structures.
### Message format
@@ -46,7 +46,7 @@ The message's unique identifier is calculated by hashing a message header and th
* `message_header = channel_id || salt || timestamp || message_length || message_type`
* `message_id = HASH("MESSAGE_ID", message_header, root_hash)`
The random salt prevents collisions between otherwise identical messages. 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.
The random salt prevents collisions between otherwise identical messages. 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 client and is not interpreted by BSP.
Each block has a unique identifier, which is calculated by hashing the message header, 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.
@@ -79,7 +79,7 @@ The current version of the protocol is 1, which has five record types:
**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 according to the application's sharing policy. 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.
The local peer is said to hold a block if it is storing the block and sharing it with the remote peer according to the client's sharing policy. 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