NFD

Junxiao Shi wrote:

• multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.

Why is it almost? What's the corner case?

A better categorization, I think, is either wired or wireless face. A wireless face should always be allowed to forward both Interest and Data to the incoming face, but a wired face should not. Then we can have a bool property like isWired or isWireless.

multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.

Wired Ethernet has no delivery guarantee. Packet loss is possible, hence "almost".

A wireless face should always be allowed to forward both Interest and Data to the incoming face

Wrong. A WiFi interface operating in STA mode only communicates with the AP. If the AP is NDN-capable, all packets received on this face is sent by the AP, and thus there's no reason to send them back.

but a wired face should not.

Correct.

multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.

Wired Ethernet has no delivery guarantee. Packet loss is possible, hence "almost".

There is no need to send packet back to the incoming face in this case.

A wireless face should always be allowed to forward both Interest and Data to the incoming face

Wrong. A WiFi interface operating in STA mode only communicates with the AP. If the AP is NDN-capable, all packets received on this face is sent by the AP, and thus there's no reason to send them back.

It is also multi-access face as you classified. If not all multi-access face should forward packet back to the incoming face, why 'multi-access face' is better than 'wireless face'?

It is also multi-access face as you classified. If not all multi-access face should forward packet back to the incoming face, why 'multi-access face' is better than 'wireless face'?

Each face is responsibility for reporting whether it's desirable for the strategy to transmit a packet received on the same face.
In the initial implementation, we make the same choice for all multi-access faces, because there is no OS-independent way to reliably identify whether a face is wireless.

Each face is responsibility for reporting whether it's desirable for the strategy to transmit a packet received on the same face.
In the initial implementation, we make the same choice for all multi-access faces, because there is no OS-independent way to reliably identify whether a face is wireless.

Currently, how do we identify whether a face is multi-access or not? As wireless belongs to multi-access, is it more different to identify a wireless face?

Currently, how do we identify whether a face is multi-access or not?

The Transport reports whether it's multi-access or not. It's easy to know when the face is created, because the procedures of creating a point-to-point face (ProtocolFactory::createFace) and creating a multi-access face (EthernetFactory::createMulticastFace and UdpFactory::createMulticastFace) are totally separate.
Then, forwarding can inspect LinkType property to know whether a face is multi-access.

As wireless belongs to multi-access, is it more different to identify a wireless face?

Yes, because you can't easily answer "is eth1 a wireless interface?". At least this is not currently in NetworkMonitor API (#3353).

How about having a similar faceType, like ndn::nfd::FACE_TYPE_POINT_TO_POINT and ndn::nfd::FACE_TYPE_MULTI_ACCESS.

I agree with note-9 design.
One concern someone may have is that, LinkType property is reported by the Transport but "ad hoc" property may belong to a higher layer. But I argue that whether the face is ad hoc should be known by the Transport, because the definition is "whether a packet received on this face is expected to have been received by all other nodes on the same link" which is a property of the underlying protocol, and not affected by LinkService.

For the constant name, how about LINK_TYPE_AD_HOC?

Junxiao Shi wrote:

For the constant name, how about LINK_TYPE_AD_HOC?

As a third (not counting _NONE) value for ndn::nfd::LinkType enum? Sounds good to me.

Seems for this task, we just need to add a constant value LINK_TYPE_AD_HOC for link type. The forwarding task can be done in another thread Ad hoc Forwarding. There is no existing transport that uses this type. How do we test it?

Reply to note-12:

There is more than that.
NFD needs a boolean configuration option, when enabled, causes all current LINK_TYPE_MULT_ACCESS faces to report as LINK_TYPE_AD_HOC.
The test is simply enabling this option, and expecting nfdc face list command to show some face's link-type attribute becomes LINK_TYPE_AD_HOC.

To avoid breaking existing logic, before the above configuration option is introduced, another commit should change all "only for point-to-point faces" conditions from != LINK_TYPE_MULTI_ACCESS to == LINK_TYPE_POINT_TO_POINT, and change all "only for multi-access faces" conditions from == LINK_TYPE_MULTI_ACCESS to != LINK_TYPE_POINT_TO_POINT. This ensures any faces now reporting as ad hoc would follow the old logic of multi-access rather than point-to-point.

I am trying to detect the mode of a WiFi interface automatically and set the proper link type accordingly. This snippet of code is used for macOS specifically.

#import <Foundation/Foundation.h>
#import <CoreWLAN/CoreWLAN.h>
#import <CoreWLAN/CWInterface.h>
#import <CoreWLAN/CWWiFiClient.h>

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        NSString* interfaceName = @"en0";
        CWWiFiClient* wifiInterface = [[CWWiFiClient alloc] init];
        CWInterface* airport = [wifiInterface interfaceWithName:interfaceName];
        NSLog(@"The mode is : %ld",(long)[airport interfaceMode]);
        if([airport interfaceMode] == 2){
            //ad hoc detected
            NSLog(@"ad hoc");
        }
    }
    return 0;
}

I am trying to detect the mode of a WiFi interface automatically and set the proper link type accordingly.

This is of course better than using a configuration. It would be acceptable if you can come up with implementations for every support platform, and it must apply to both Ethernet and UDP multicast faces.

Junxiao Shi wrote:

It would be acceptable if you can come up with implementations for every support platform

On Linux, nl80211 can be used for this purpose.

I strongly recommend that the "ad hoc" property should be initially implemented as following a configuration option. Attempting platform-specific implementations would take much longer time (remember what happened in #3353) and block related issues (such as forwarding changes).

@Junxiao: "Duplicate" has different semantics in current configuration of redmine, as only one task is being tracked (the source of "duplicated by"). The duplicate task is considered closed.

macOS version pushed for review (as part of ndn-cxx API): https://gerrit.named-data.net/#/c/3798/