NFD

Please paste a TLVDUMP output of the dataset you are seeing.

It can be observed using nfd-status from http://gerrit.named-data.net/#/c/887/.

Here is the output from nfd-tlv-peek with tlvdump:

cawka@cawka-mac NFD (master)]$ ndn-tlv-peek /localhost/nfd/faces/channels | tlvdump

6 (Data) (size: 688)
  7 (Name) (size: 46)
    8 (NameComponent) (size: 9) [[localhost]]
    8 (NameComponent) (size: 3) [[nfd]]
    8 (NameComponent) (size: 5) [[faces]]
    8 (NameComponent) (size: 8) [[channels]]
    8 (NameComponent) (size: 8) [[%00%00%01Fz%A0ex]]
    8 (NameComponent) (size: 1) [[%00]]
  20 (MetaInfo) (size: 5)
    26 (FinalBlockIdSignatureType) (size: 3)
      8 (NameComponent) (size: 1) [[%00]]
  21 (Content) (size: 294)
    130 (APP_TAG_1) (size: 34)
      129 (APP_TAG_1) (size: 32) [[unix%3A%2F%2F%2Fprivate%2Fvar%2Frun%2Fnfd.sock]]
    130 (APP_TAG_1) (size: 18)
      129 (APP_TAG_1) (size: 16) [[udp6%3A%2F%2F%5B%3A%3A%5D%3A6363]]
    130 (APP_TAG_1) (size: 21)
      129 (APP_TAG_1) (size: 19) [[udp4%3A%2F%2F0.0.0.0%3A6363]]
    130 (APP_TAG_1) (size: 18)
      129 (APP_TAG_1) (size: 16) [[udp6%3A%2F%2F%5B%3A%3A%5D%3A6363]]
    130 (APP_TAG_1) (size: 21)
      129 (APP_TAG_1) (size: 19) [[udp4%3A%2F%2F0.0.0.0%3A6363]]
    130 (APP_TAG_1) (size: 18)
      129 (APP_TAG_1) (size: 16) [[udp6%3A%2F%2F%5B%3A%3A%5D%3A6363]]
    130 (APP_TAG_1) (size: 21)
      129 (APP_TAG_1) (size: 19) [[udp4%3A%2F%2F0.0.0.0%3A6363]]
    130 (APP_TAG_1) (size: 18)
      129 (APP_TAG_1) (size: 16) [[tcp6%3A%2F%2F%5B%3A%3A%5D%3A6363]]
    130 (APP_TAG_1) (size: 21)
      129 (APP_TAG_1) (size: 19) [[tcp4%3A%2F%2F0.0.0.0%3A6363]]
    130 (APP_TAG_1) (size: 18)
      129 (APP_TAG_1) (size: 16) [[tcp6%3A%2F%2F%5B%3A%3A%5D%3A6363]]
    130 (APP_TAG_1) (size: 21)
      129 (APP_TAG_1) (size: 19) [[tcp4%3A%2F%2F0.0.0.0%3A6363]]
    130 (APP_TAG_1) (size: 18)
      129 (APP_TAG_1) (size: 16) [[tcp6%3A%2F%2F%5B%3A%3A%5D%3A6363]]
    130 (APP_TAG_1) (size: 21)
      129 (APP_TAG_1) (size: 19) [[tcp4%3A%2F%2F0.0.0.0%3A6363]]
  22 (SignatureInfo) (size: 73)
    27 (KeyLocator) (size: 1) [[%01]]
    28 (KeyLocatorDigest) (size: 68)
      7 (Name) (size: 66)
        8 (NameComponent) (size: 21) [[ndn-cxx-test-identity]]
        8 (NameComponent) (size: 8) [[%00%00%01F%17%C0%C4%26]]
        8 (NameComponent) (size: 3) [[KEY]]
        8 (NameComponent) (size: 17) [[ksk-1400557847592]]
        8 (NameComponent) (size: 7) [[ID-CERT]]
  23 (SignatureValue) (size: 256) [[rL%ABZ%85%3A%E5Gc%ED%0F%C6%01eW%E4%83%BF%1F%DF%F8%7F%5E%93J%F7%8C%BD%D6D%E0A%B9%92%90%15%98%B3%D6o%E1%AF%DD%05%03%DBP.%E1%A4_%07E%A9%07%E5%BE%0BD%8A%15%26T%B6%F6%81A%92%9D%EA%03%26%5C%C0%A4%E0%EEt5%8D%C0%A2%2F%0C%A7%5B_-%D2%26%CCB%DD%BD%FA%A0%EF%3F%C8T%83%D7%E6%FEGn%C1X%A0%8F%F3%96hS%CCC%22%7Fp%CA%EEP%B2%8A%ECf-6%F1%D5e%7F%95%40%1D%BB%05dE%A4%EC%26%86%10%D8%97%2CS%F9M%3A%B1%81%DC%D4%85%5C%8FO%CC%9D%F8%E6%E3+%94%3B%94w%7C%D7%22%E4%DF.%AA%16%25%BCR%FE%B4%9EVh%F7f%BAQB%15%EC2%98%C5%C7F+%F1%DE%0Bi%8A%21%7B%ECo%B3%96J8d%B2%15%C3%2A%8BNr%A2az%BFN%0D%1F%AF%F5E%B8%D9%9F%3E%1E%B9%14o%21%A9%ABu%A1g%F0C%90%03u%8E%EB1%405%9A6%B0]]

I think I know what the problem is, and you're right, it's the dataset creation. I'm iterating over the face manager's factory mapping to ask for the channels. tcp and udp are duplicated as "tcp", "tcp4", and "tcp6" (same for udp).

I'll correct this by only publishing unique URIs in the dataset publisher.

Actually, that's not what's going on here: it's duplicated within a protocol (2 of the same udp4 URIs and such). I think the suggested fix would solve the problem, but I'm going to dig around to see what's causing this to happen in the first place. It might not be the publisher...

No no. You correctly pointed out the reason: the same factory in tcp and udp cases is added to m_factories three times. Once it is with "udp" key, once with "udp4", and once with "udp6". The actual channels inside the factory are only "udp4" and "udp6", so that's why we see the same two channels published three times.