SpreadProtocol¶

• SpreadProtocol
  • Data Format
  • Fragmentation
  • Hierarchical Bus
  • Group Names
  • Quality of Service
  • Implementations

This wiki page describes the protocol used by the Spread-based connectors.

Data Format¶

Data exchanged on the wire by the Spread-based transport is encoded using Google protocol buffers. A Spread message always contains a fragment of a notification (source:/trunk/protocol/rsb/protocol/FragmentedNotification.proto) as elementary communication unit. Descriptions of the Notification contents are given as comments on the descriptor files.

Fragmentation¶

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 FragmentedNotification s which are sent sequentially. Multiple FragmentedNotification objects are constructed according to the following rules:

• The size of individual fragments (i.e. serialized size of the FragmentedNotification objects) must not exceed 100,000 octets
• Fragment numbers are in the range [0, NUMBER-OF-FRAGMENTS - 1]
• The fields which differ among FragmentedNotification s for one event are:
  • The number of the fragment (FragmentedNotification.data_part field)
  • The paylod data (FragmentedNotification.notification.data field)
  • Which fields of the Notification embedded in FragmentedNotification.notification are present (see below)
• Each of the FragmentedNotification objects contains a Notification object
  • The id of the event (Notification.event_id field) is always present (to specify the event to which a fragment belongs)
  • For the initial fragment (fragment number 0), all fields of the embedded Notification object are present
  • For subsequent fragments (fragment number >= 1), only the following fields of the embedded Notification object are present:
    • Notification.event_id
    • Notification.data

Hierarchical Bus¶

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).

Example

super-scopes(/foo/bar/, include-self? = yes) = /, /foo/, /foo/bar/

Group Names¶

Group names are created by applying the following steps to the fully formal scope string representation (including trailing slash):

1. Hash the scope string using MD5.
2. Convert the 16 bytes of output to a 32 character string by concatenating the zero-padded hex (base-16) representations of the individual bytes.
   Letters of the hex representation have to be lower case.
3. Remove the final character of the hex representation of the hash.
   (Since spread group names can only be 32 bytes long including the 0-terminator)

Example

/         -> "6666cd76f96956469e7be39d750cc7d\0" 
/foo/     -> "4f87be8f6e593d167f5fd1ab238cfc2\0" 
/foo/bar/ -> "1c184f3891344400380281315d9e738\0" 

Quality of Service¶

The following table explains how the 2D RSB QoS settings are mapped to spread message types.

	UNRELIABLE	RELIABLE
UNORDERED	UNRELIABLE_MESS	RELIABLE_MESS
ORDERED	FIFO_MESS	FIFO_MESS

Implementations¶

Language	File(s)/Directory
C++	source:trunk/cpp/core/src/rsb/transport/spread
Java	source:trunk/java/core/src/rsb/transport/spread
Python	source:trunk/python/core/rsb/rsbspread/__init__.py
Common Lisp	source:trunk/cl/cl-rsb/src/transport/spread