Project

General

Profile

Feature #4467

Export GenericLinkService counters

Added by Davide Pesavento almost 2 years ago. Updated 6 months ago.

Status:
In Progress
Priority:
Normal
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

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

History

#1 Updated by Davide Pesavento almost 2 years ago

  • Description updated (diff)

#2 Updated by Alex Afanasyev almost 2 years ago

  • Assignee set to Rajender Kumar

#3 Updated by Rajender Kumar 12 months ago

  • Status changed from New to In Progress

#4 Updated by Junxiao Shi 12 months 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.

#5 Updated by Rajender Kumar 12 months 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

#6 Updated by Davide Pesavento 11 months 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.

#7 Updated by Junxiao Shi 6 months ago

  • Blocked by Feature #4600: Redesign NFD Management protocol to use Interest Parameters added

#8 Updated by Junxiao Shi 6 months 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.

Also available in: Atom PDF