RDR » History » Version 5
Davide Pesavento, 10/25/2018 02:05 PM
| 1 | 1 | Junxiao Shi | # Realtime Data Retrieval (RDR) protocol |
|---|---|---|---|
| 2 | |||
| 3 | 5 | Davide Pesavento | [Real-Time Data Retrieval in Named Data Networking](https://named-data.net/publications/hoticn18realtime-retrieval/) published in HotICN'18 introduces Real-time Data Retrieval (RDR) protocol for discovering the latest version number of real-time streaming data. |
| 4 | This document defines the recommended packet format of the RDR protocol. |
||
| 5 | 1 | Junxiao Shi | |
| 6 | 2 | Chavoosh Ghasemi | RDR is an application-level protocol, and its usage could be application specific. |
| 7 | 5 | Davide Pesavento | Therefore, it is RECOMMENDED that each application defines its own instance of the RDR protocol based on this document, rather than directly referencing this specification. |
| 8 | 1 | Junxiao Shi | |
| 9 | ## Metadata Packet |
||
| 10 | |||
| 11 | 5 | Davide Pesavento | In RDR, the *metadata packet* is a Data packet that carries the latest version number of a data stream. |
| 12 | 1 | Junxiao Shi | |
| 13 | ### Name Suffix |
||
| 14 | |||
| 15 | The name of a metadata packet MUST end with these three name components: |
||
| 16 | |||
| 17 | 1. The keyword component `32=metadata`, indicating this Data packet is a metadata packet under this specification. |
||
| 18 | 2. A version number component, whose format is defined in Naming Conventions. |
||
| 19 | 5 | Davide Pesavento | 3. A segment number component, whose format is defined in Naming Conventions. Normally the metadata is not segmented and thus the segment number is zero, but this component is included for future extensions. |
| 20 | 1 | Junxiao Shi | |
| 21 | ### Name Prefix |
||
| 22 | |||
| 23 | 5 | Davide Pesavento | The name prefix of a metadata packet before the above three name components SHOULD be the same as the name of the versioned data up to (and not including) its version number component. |
| 24 | For example, an application can have the following namespace: |
||
| 25 | 1 | Junxiao Shi | |
| 26 | ``` |
||
| 27 | # data stream |
||
| 28 | /net/example/www/frontpage/%FD%97%47%1E%6C/%00%00 |
||
| 29 | /net/example/www/frontpage/%FD%97%47%1E%6C/%00%01 |
||
| 30 | /net/example/www/frontpage/%FD%97%47%1E%6D/%00%00 |
||
| 31 | /net/example/www/frontpage/%FD%97%47%1E%6D/%00%01 |
||
| 32 | |||
| 33 | # metadata packet |
||
| 34 | /net/example/www/frontpage/32=metadata/%FD%7E%5F%45%08/%00%00 |
||
| 35 | ``` |
||
| 36 | |||
| 37 | ### FreshnessPeriod |
||
| 38 | |||
| 39 | 5 | Davide Pesavento | *FreshnessPeriod* of a metadata packet MUST NOT be zero. |
| 40 | 1 | Junxiao Shi | See the RDR paper for guidelines on an appropriate value for this field. |
| 41 | |||
| 42 | ### Content Payload |
||
| 43 | |||
| 44 | 5 | Davide Pesavento | The Content of a metadata packet MUST be a sequence of TLV elements. At least one of the TLV elements MUST be a *Name* element. The first *Name* element indicates the versioned name of the latest version of the data; additional *Name* elements, if any, are ignored. |
| 45 | 1 | Junxiao Shi | |
| 46 | For example: |
||
| 47 | |||
| 48 | ``` |
||
| 49 | <Content> |
||
| 50 | <ArbitraryElement>this is ignored</ArbitraryElement> |
||
| 51 | <Name>/net/example/www/frontpage/%FD%97%47%1E%6D</Name> |
||
| 52 | <Name>this is ignored</Name> |
||
| 53 | </Content> |
||
| 54 | ``` |
||
| 55 | |||
| 56 | ## RDR Discovery Interest |
||
| 57 | |||
| 58 | 5 | Davide Pesavento | In the RDR protocol, consumers express RDR Discovery Interests to retrieve metadata packets, in order to discover the latest version number of the data stream. |
| 59 | 1 | Junxiao Shi | An RDR Discovery Interest MUST: |
| 60 | |||
| 61 | 5 | Davide Pesavento | * carry a name that ends with a `32=metadata` keyword component |
| 62 | * contain *CanBePrefix* |
||
| 63 | * contain *MustBeFresh* |