Pre-authentication messages ¶ĪFTER establishing a connection, but BEFORE performing any authentication, Way to represent the folder, perhaps by using the ID in it’s place orĪutomatically generating a label. However the folder label is for human consumption only so anĮmpty label should be accepted - the implementation will have to choose some Message is valid with all fields empty - for example, an index entry for aįile that does not have a name is not useful and MAY be rejected by the Means, among other things, that all fields are optional and will assume The protocol buffer schemas in this document are in proto3 syntax. When describing message lengths negative values do not make sense and the Non protocol buffer integers are always represented in networkīyte order (i.e., big endian) and are signed unless stated otherwise, but Significant bit of a word “bit 15” is thus the least significant bit of aġ6 bit word (int16) and “bit 31” is the least significant bit of a 32 bit In this document, in diagrams and text, “bit 0” refers to the most The underlying transport protocol MUST guarantee reliable packet delivery. The sender need not await a response to one message before sending There is no required order or synchronization among BEP messages exceptĪs noted per message type - any message type may be sent at any time and The reference implementation uses preshared certificateįingerprints (SHA-256) referred to as “Device IDs”. Or certificate pinning combined with some out of band first Trusted CA, preshared certificates, preshared certificate fingerprints Possibilities include certificates signed by a common It SHALL be based on the TLS certificate presented at the start of theĬonnection. The exact nature of the authentication is up to the application, however This is not to be taken as anĮxhaustive list of allowed cipher suites but represents best practices Suite” being defined as being without known weaknesses and providing A strong cipher suite SHALL be used, with “strong cipher The encryption and authentication layer SHALL use TLS 1.2 or a higher +-+ | Block Exchange Protocol | |-| | Encryption & Auth ( TLS 1.2 ) | |-| | Reliable Transport | |-| v. Level protocols providing encryption and authentication. Transport and Authentication ¶īEP is deployed as the highest level in a protocol stack, with the lower “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in thisĭocument are to be interpreted as described in RFC 2119. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, Theīlock size may vary between files but is constant in any given file, except With the global model by requesting missing or outdated blocks from theįile data is described and transferred in units of blocks, each being fromġ28 KiB (131072 bytes) to 16 MiB in size, in steps of powers of two. Each device strives to get its folders in sync The union of allįiles in the local models, with files selected for highest change version,įorms the global model. Local model is sent to the other devices in the cluster. Each device has one or more folders of filesĭescribed by the local model, containing metadata and block hashes. The Block Exchange Protocol (BEP) is used between two or more devices thusįorming a cluster. Block Exchange Protocol v1 ¶ Introduction and Definitions ¶
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |