SpreadProtocol » History » Version 16
J. Moringen, 06/17/2011 08:54 PM
updated fragmentation section, fixed link to Notification protocol buffer descriptor
1 | 1 | J. Wienke | h1. SpreadProtocol |
---|---|---|---|
2 | 1 | J. Wienke | |
3 | 1 | J. Wienke | This wiki page describes the protocol used by the spread-based connectors. |
4 | 1 | J. Wienke | |
5 | 1 | J. Wienke | h2. Data Format |
6 | 1 | J. Wienke | |
7 | 16 | J. Moringen | Data exchanged on spread is encoded using Google protocol buffers. A spread message always contains a notification (source:/trunk/protocol/RSBProtocol/Protocol.proto) as elementary communication unit. Descriptions of the Notification contents are given as comments on the descriptor file. |
8 | 1 | J. Wienke | |
9 | 16 | J. Moringen | h2. Fragmentation |
10 | 1 | J. Wienke | |
11 | 16 | J. Moringen | Because spread has a message size limit, a single @Notification@ may not be sufficient to transport a whole event with a huge amount of user data. Hence, events may be encoded in several @Notification@ s sent subsequently. In this case the multiple @Notification@ objects are constructed according to the following rules: |
12 | 16 | J. Moringen | * The size of individual fragments (i.e. the values of @Notification.data@) must not exceed 100,000 octets |
13 | 16 | J. Moringen | * Fragment number are in the range [0, NUMBER-OF-FRAGMENTS - 1] |
14 | 16 | J. Moringen | * Most field values are repeated in all @Notification@ s, in particular: |
15 | 16 | J. Moringen | ** The id of the event (@Notification.id@ field) |
16 | 16 | J. Moringen | ** The number of @Notification@ s into which the event has been split (@Notification.num_data_parts@ field) |
17 | 16 | J. Moringen | * The two fields which differ among @Notification@ s for one event are: |
18 | 16 | J. Moringen | ** The index of the data chunk encoded in the Notification (@Notification.data_part@ field). |
19 | 16 | J. Moringen | ** The user data (@Notification.data@ field) are split. |
20 | 2 | J. Wienke | |
21 | 13 | J. Moringen | h2. Hierarchical Bus |
22 | 2 | J. Wienke | |
23 | 8 | J. Moringen | The hierarchical bus is created by sending each message to a group corresponding to its scope as well as groups corresponding to all super scopes including "/" (multigroup mulitcast). |
24 | 8 | J. Moringen | |
25 | 8 | J. Moringen | _Example_ |
26 | 8 | J. Moringen | <pre> |
27 | 1 | J. Wienke | super-scopes(/foo/bar/, include-self? = yes) = /, /foo/, /foo/bar/ |
28 | 8 | J. Moringen | </pre> |
29 | 2 | J. Wienke | |
30 | 13 | J. Moringen | h2. Group Names |
31 | 3 | J. Wienke | |
32 | 10 | J. Moringen | Group names are created by applying the following steps to the fully formal scope string representation (*including trailing slash*): |
33 | 10 | J. Moringen | # Hash the scope string using "MD5":http://en.wikipedia.org/wiki/MD5. |
34 | 10 | J. Moringen | # Convert the 16 bytes of output to a 32 character string by concatenating the *zero-padded* hex (base-16) representations of the individual bytes. |
35 | 10 | J. Moringen | Letters of the hex representation have to be lower case. |
36 | 10 | J. Moringen | # Remove the final character of the hex representation of the hash. |
37 | 10 | J. Moringen | (Since spread group names can only be 32 bytes long _including the 0-terminator_) |
38 | 7 | J. Moringen | |
39 | 7 | J. Moringen | _Example_ |
40 | 7 | J. Moringen | <pre> |
41 | 9 | J. Moringen | / -> "6666cd76f96956469e7be39d750cc7d\0" |
42 | 1 | J. Wienke | /foo/ -> "4f87be8f6e593d167f5fd1ab238cfc2\0" |
43 | 9 | J. Moringen | /foo/bar/ -> "1c184f3891344400380281315d9e738\0" |
44 | 7 | J. Moringen | </pre> |
45 | 4 | J. Wienke | |
46 | 13 | J. Moringen | h2. Quality of Service |
47 | 4 | J. Wienke | |
48 | 4 | J. Wienke | The following table explains how the 2D RSB QoS settings are mapped to spread message types. |
49 | 4 | J. Wienke | |
50 | 5 | J. Wienke | ||_.UNRELIABLE|_.RELIABLE| |
51 | 5 | J. Wienke | |_.UNORDERED|UNRELIABLE_MESS|RELIABLE_MESS| |
52 | 5 | J. Wienke | |_.ORDERED|FIFO_MESS|FIFO_MESS| |