Task #1177
closed
- Assignee set to Alex Afanasyev
- 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.
Another question. Should the format for status protocol be also TLV?
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.
Let's use TLV for cleaner and simpler forwarder and library.
- Estimated time set to 3.00 h
Representation of underlying address should be same as Face Management protocol.
- Category changed from Management to Protocol
- Priority changed from Normal to High
- Description updated (diff)
- Status changed from New to In Progress
- % Done changed from 0 to 60
- 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.
- Status changed from Feedback to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by