FludProtocol2
From flud
[edit] Data Storage Primitives
The data storage primitives are directed singly at a destination target. That is, each of these messages contains a host:port pair designating the target of the operation.
-
GET /ID- The peer returns its unique node ID.
-
POST /file/[filekey]- The peer stores the data forfilekey.
-
GET /file/[filekey]- The peer returns the data stored underfilekey.
-
DELETE /file/[filekey]- The peer deletes the data stored underfilekey.
-
GET /hash/[filekey]/[offset]/[length]- The peer hashes the data stored underfilekeyfrom positionoffsetand consisting oflengthbytes, and returns the result.
[edit] Metadata Storage Primitives
The metadata storage primitives are routed via an overlay network modeled after the Kademlia protocol. The /ID() data storage operation (above) is used as a PING() operator.
-
GET /node/[val]- Peer returns the node(s) with nodeID closest toval.
-
POST /dht/[key]/[val])- Peer storesvalunderkey.
-
GET /dht/[key]- Peer returns the value stored underkey, if present.
Since kademlia operations are parallel and iterative, nodes will invoke the above operations via a global interface:
-
kFINDNODE(val)- Returns the node(s) with nodeIDs closest toval. This invokes multipleGET /node/[val]to peers. This is the client's 'Find' operation. -
kPUT(key, val)- Storesvalunderkey. Storage occurs on k nodes with nodeIDs closest tokey. This is the client 'PUT' operation. -
kGET(key)- Returns the value stored underkey, if present. This invokes multipleGET /dht/[key]to peers. This is the client 'GET' operation
-
The top-level operations are the only operations required for the server-side to implement. The client-side implements the second-level primitives, which may invoke multiple top-level primitives. For example, GET /node/[val] will generate responses for the k-closest nodes to val that a single peer knows of. kFINDNODE(val), on the other hand, will call GET /node/[val] multiple times, resulting in a global list of the k-closest nodes to val.