Project

General

Profile

Protocols » History » Version 25

Greg Burri, 09/27/2012 10:41 PM

1 1 Greg Burri
h1. Protocols
2
3 25 Greg Burri
* [[Protocol core-core Version 1]]
4
* [[Protocol core-core Version 4]]
5 4 Greg Burri
* [[Protocol core-GUI]]
6
7 18 Greg Burri
There is two main protocols, one between cores and one between GUI and core. Both are using "protocol buffers":http://code.google.com/p/protobuf/ for describing the exchanged messages.
8 1 Greg Burri
9 5 Greg Burri
Each data sent over the network (using TCP or UDP) are formatted like this :
10 3 Greg Burri
11
<pre>
12 14 Greg Burri
<messageType:uint32><size:uint32><senderId:20*uint8><serializedMessage>
13 3 Greg Burri
</pre>
14
15
Where :
16
* _messageType_ is a number which determine the message type, more information in the proto files.
17 19 Greg Burri
* _size_ is the size of the following serialized message. It may be zero for an empty message.
18 12 Greg Burri
* _senderId_ is the sender id.
19 1 Greg Burri
* _serializedMessage_ is the data serialized by protocol buffer.
20 12 Greg Burri
21 15 Greg Burri
The first three items is the header and is exactly 28 bytes long.
22 12 Greg Burri
23 6 Greg Burri
24
25 9 Greg Burri
h2. Links to resource (DRAFT)
26 6 Greg Burri
27 17 Greg Burri
h3. Proposal 1
28
29 10 Greg Burri
Links can be shared across peers. It locates a remote resource like folder or file from a specific peer. It can contain chunk hashes, thus the source peer doesn't need to be online to download a file or a folder.
30 6 Greg Burri
31 16 Greg Burri
_dl://[<peer name>][:<file id>][:<shared id>/<folder>/<file>]_
32 6 Greg Burri
33 7 Greg Burri
* <peer name> : Not required and not used to locate the resource, just an information for the user.
34
* <file id> : its the n first group of nibble of the m first chunk where _n * m = 40 nibbles_ (20 octets).
35
** 20,87cace382f7371cd3fab3cb0a53b93b7cd9719f6 : 20 chunks of 2 nibbles.
36
** 8,05649bcbf065e0d032ada540d4a749d98db055cf : 8 chunks of 5 nibbles.
37
* <shared id> : Contains only the beginning of the hash.
38 6 Greg Burri
39 1 Greg Burri
40 17 Greg Burri
h4. Examples
41 6 Greg Burri
42 1 Greg Burri
* _dl://20,87cace382f7371cd3fab3cb0a53b93b7cd9719f6_
43
* _dl://pierre:20,87cace382f7371cd3fab3cb0a53b93b7cd9719f6_
44
* _dl://pierre:20,87cace382f7371cd3fab3cb0a53b93b7cd9719f6:dac4f75c/my%20movies/LOLCat.avi_
45
* _dl://pierre:dac4f75c/my%20movies/LOLCat.avi_
46
* _dl://pierre:dac4f75c/my%20movies_
47 17 Greg Burri
48
49
h3. Proposal 2
50
51
This version is much simpler, it doesn't identify the file and contains only the path to the ressource.
52
53
_dl://<peer name>(<peer ID>)<path>_
54
55
_<path>_ always starts with a slash. It can be a folder or a file.
56
57 20 Greg Burri
h4. Examples
58 1 Greg Burri
59 20 Greg Burri
* _dl://pierre(d51f479)/my%20movies/LOLCat.avi_
60
61
h3. Proposal 3
62 1 Greg Burri
63 23 Greg Burri
Folders: _dl://[<peer name>]:[<peer id>]:(<shared id>|<shared name>)[/<path>]/_
64
Files: _dl://<file id>:<file size>:<file name>_
65 20 Greg Burri
66 22 Greg Burri
<file id> is a hash built from all the chunk hashes. A new field must be added to the IMAlive message to ask if someone know a particular file ID, is someone know the file ID then he replies with a ChunksOwned message (rename the message?) with a field named file_state.
67
68 20 Greg Burri
h4. Examples
69
70
* _dl://Pierre::a%20shared%20folder/my%20movies/_
71
* _dl://Pierre:7c0215d7f758bce8d00ffc467be7d5f5f7c9f929:a%20shared%20folder/my%20movies/_
72
* _dl://Pierre:7c0215d7f758bce8d00ffc467be7d5f5f7c9f929:68181cd1c7495122493b74170f76700ac30c81d1/my%20movies/_
73 24 Greg Burri
* _dl://ea627f2d65c12a78aa5c0c154ba7e187d3fefe80:my%20movies/LOLCat.avi_