Project

General

Profile

Actions

Feature #4467

open

Export GenericLinkService counters

Added by Davide Pesavento about 6 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Management
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

The counters in GenericLinkService::Counters are currently completely inaccessible, and therefore rather useless. They should be exposed via NFD's Face Management API.
If possible, we should design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added.


Related issues 1 (1 open0 closed)

Blocked by NFD - Feature #4600: Redesign NFD Management protocol to use ApplicationParametersNew

Actions
Actions #1

Updated by Davide Pesavento about 6 years ago

  • Description updated (diff)
Actions #2

Updated by Alex Afanasyev about 6 years ago

  • Assignee set to Rajender Kumar
Actions #3

Updated by Rajender Kumar over 5 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Junxiao Shi over 5 years ago

I think the important thing to get right in #4467 is the following: "design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added".
I'm not sure if I can agree with the current direction of "manually" adding every single counter (+getter/setter) to ndn-cxx.

If you only concern is implementing getter and setter: this can be automated.
I wrote (and lost) a script that takes variable declarations (e.g. uint64_t m_nInInterests;) and generates has+get+set+clear functions.

Another potential problem is that, in the long run, it might not be a good idea to keep adding lots of (rarely used) counters to FaceStatus, as it makes retrieving the status and the list of faces more and more expensive (the linux kernel faced a similar problem some time ago).

Modern web technology's answer to this problem is GraphQL.
Maybe we should move away from TLV and adopt GraphQL+JSON.

Actions #5

Updated by Rajender Kumar over 5 years ago

Junxiao Shi wrote:

I think the important thing to get right in #4467 is the following: "design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added".
I'm not sure if I can agree with the current direction of "manually" adding every single counter (+getter/setter) to ndn-cxx.

So Can you suggest some idea to achieve this? Is it a good idea to use a container like a map or (key, value) pair for counters.

If you only concern is implementing getter and setter: this can be automated.
I wrote (and lost) a script that takes variable declarations (e.g. uint64_t m_nInInterests;) and generates has+get+set+clear functions.

Another potential problem is that, in the long run, it might not be a good idea to keep adding lots of (rarely used) counters to FaceStatus, as it makes retrieving the status and the list of faces more and more expensive (the linux kernel faced a similar problem some time ago).

Modern web technology's answer to this problem is GraphQL.
Maybe we should move away from TLV and adopt GraphQL+JSON.

I will think about GraphQL

Actions #6

Updated by Davide Pesavento over 5 years ago

Junxiao Shi wrote:

I think the important thing to get right in #4467 is the following: "design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added".
I'm not sure if I can agree with the current direction of "manually" adding every single counter (+getter/setter) to ndn-cxx.

If you only concern is implementing getter and setter: this can be automated.

No, that's not my concern at all. What I want to avoid is having to modify the library for every new counter introduced. It's not "just" the getter/setter but all the hand-written serialization/deserialization code. And it's not even about the "hand-written" part, but about the fact that the library needs to be aware of the new counter type.

Another potential problem is that, in the long run, it might not be a good idea to keep adding lots of (rarely used) counters to FaceStatus, as it makes retrieving the status and the list of faces more and more expensive (the linux kernel faced a similar problem some time ago).

Modern web technology's answer to this problem is GraphQL.
Maybe we should move away from TLV and adopt GraphQL+JSON.

Maybe, although GraphQL seems overkill, I supported moving away from TLV for management years ago. But here I was merely saying that extracting all the detailed counters should be a separate management API endpoint, or enabled via a flag on the existing face status endpoint.

Actions #7

Updated by Junxiao Shi almost 5 years ago

  • Blocked by Feature #4600: Redesign NFD Management protocol to use ApplicationParameters added
Actions #8

Updated by Junxiao Shi almost 5 years ago

we should design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added.

Part of #4600 is to switch Management encoding from TLV to CBOR, fulfilling this desire.

Actions #9

Updated by Davide Pesavento over 1 year ago

  • Status changed from In Progress to New
  • Assignee deleted (Rajender Kumar)
Actions

Also available in: Atom PDF