NLSR

I assume that NFD has a way to dump the Faces it has as a dataset of some sort. This will be needed for this patch no matter what, I think.

Does NFD know which routers it wants NLSR to route to? If it does, then we have two options:

1. NFD will dump to NLSR a set of only those Faces that it wants NLSR to route to, and NLSR will blindly use them, or
2. NFD will dump all of its Faces to NLSR and NLSR will choose from them the ones that match in its configuration file.

Even if this information isn't already in NFD, it seems like a good idea. I feel that option 1 is preferable, for these reasons:

1. It will simplify miniNDN by eliminating the highly-variable neighbor configuration,
2. It is more secure in that NLSR isn't given unlimited access to NFD's information,
3. It fits more closely to the idea that NLSR is a "helper" program to NFD, and
4. It means NLSR the percentage of things that NLSR is doing that are routing goes up and that are other things goes down.

The alternative is just that NLSR will have to continue having a configuration file. I suspect that permanent Faces could do something to solve this problem, in that Faces going up/down would just be a matter of changing Face state. So,

• Does NFD have a way to give NLSR only the Faces it wants routing done for?
• Does NFD currently have a way to dump Faces?
• Is there currently enough information in the Face event stream to keep the configuration file out of NLSR?

Answer to note-5:

NFD provides a list of faces through FaceMgmt face dataset.
There's also a FaceMgmt face query operation which allows some filtering.

NFD does not and should not know which faces should routing be enabled on. It's not NFD's responsibility.

An analogy is a software IP router: the Linux kernel does not know which physical interfaces should dynamic routing be enabled on; Quagga configuration file controls that.

An operator may configure both with the same initialization script, which looks like:

nfdc face create udp4://192.0.2.2:6363 permanent
FACEID=(parse nfdc output to get faceid)
nlsrc adj create $FACEID /example/router-192-0-2-2

When NLSR receives a FaceEventNotification of the type destroyed, does that mean that the prefixes anchored at that Face URI have been unregistered, too?

Currently, NLSR registers three prefixes (broadcast, LSA, sync) on the Face URI for each neighbor that it has, and it does this whenever HelloProtocol receives an Interest from a neighbor it hasn't before.

Will NFD unregister those prefixes automatically? My guess is that those prefixes remain in place, because there is currently no logic in NLSR to re-register them, and also because the Faces are Permanent in NFD, the only reason to unregister them would be for cleanliness.

My previous update was answered verbally in the 10/04/16 NFD call:

If the Face is a permanent one, then the prefixes registered for it will remain vaild when that Face is down; NFD will not do anything to them.

The prefixes will be unregistered in both the standard and permanent cases if the Face is destroyed. Further, this is the only case for standard Faces.

Taking direction from another patch I'm working on, I've decided to break this one up into multiple steps, to hopefully facilitate faster code review. The steps I've identified are:

1. NLSR requests the Face dataset from NFD.
2. NLSR scrapes information from the dataset to configure its links to neighbors.
3. Intermittent re-requesting of the dataset to ensure consistency.
4. Listen to FaceUp/FaceDown requests and respond by setting HelloProtocol status.

I have run into a design roadblock: I don't want to use callbacks as an async mechanism, because they make the code very difficult to read. However, it seems that callbacks are the best approach, because they provision their own scope, and it makes them flexible. It's this scoping problem that makes lambdas unsuitable for this (generally), and it entirely prevents their use with regards to putting some async code in the middle of a function.

I was considering futures/promises to solve this problem, but it does not seem like there is a solution that will "pause" the function where it is, move on to other functions, and when the async value that was requested is available, "resume" that function. The problem with futures/promises is that they block the thread, which is unacceptable even for small values, considering that NLSR's single thread has a lot of responsibilities.

I don't really know how to eliminate ugly, hard-to-maintain callback chains without completely re-building NLSR to be more multi-threaded. I would really appreciate any design ideas or feedback regarding this.

Callbacks are widely used in NDN development. If it's just a readability issue, then I'd say you should use callbacks, which are, as you said, more flexible than lambdas.