Task #1177
closed
Face status protocol
60%
Description
Define a protocol to retrieve a list of faces, face descriptions (eg. addresses), and face counters.
This protocol should be based on ControlCommand.
Protocol: FaceStatus
Updated by Alex Afanasyev almost 11 years ago
- Description updated (diff)
- Assignee changed from Alex Afanasyev to Junxiao Shi
The final implementation of the status protocol should be aware that the returned content can get segmented. For the first round, we can ignore this and assume that result is always fits into one data packet and just truncate data if too much.
How exactly segmentation should be done is TBD.
Updated by Alex Afanasyev almost 11 years ago
Another question. Should the format for status protocol be also TLV?
Updated by Junxiao Shi almost 11 years ago
Alex Afanasyev wrote:
Another question. Should the format for status protocol be also TLV?
TLV makes the design clean and consistent with other protocols.
JSON / YAML makes the result easier to use.
Updated by Beichuan Zhang almost 11 years ago
Let's use TLV for cleaner and simpler forwarder and library.
Updated by Junxiao Shi almost 11 years ago
- Estimated time set to 3.00 h
Representation of underlying address should be same as Face Management protocol.
Updated by Junxiao Shi almost 11 years ago
- Category changed from Management to Protocol
Updated by Junxiao Shi almost 11 years ago
- Description updated (diff)
- Status changed from New to In Progress
- % Done changed from 0 to 60
Updated by Junxiao Shi almost 11 years ago
- Status changed from In Progress to Feedback
20140212 conference call reviewed FaceStatus revision 2, and changes are made.
For list faces operation, we decided:
- In the implementation, segments should be injected into the ContentStore. As long as the ContentStore has reasonable size, this is safe.
- Ideally, ContentStore should have a hold on guarantee that guarantees a Data packet to be admitted and stored for certain period of time.
- An alternate to segmentation is to have Interests like
/localhost/nfd/face/list/minid=0//localhost/nfd/face/list/minid=56/(similar to Twitter API), but this design requires additional work on the client. - Each counter should have its own TLV-TYPE to minimize the bytes transferred.
- Face status protocol should use TLV-TYPE numbers from application range.
Face status notification stream design is sent to NRD developers for review.
Updated by Junxiao Shi almost 11 years ago
- Status changed from Feedback to Closed