Feature #5277
open
Remove persistent faces
0%
Description
As discussed in 20181119 NFD call, persistent semantics shall be removed from all face types, keeping only on-demand and permanent levels.
Updated by Junxiao Shi 9 months ago
- Related to Task #4717: Clarify FacePersistency semantics added
Updated by Junxiao Shi 4 months ago
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
https://gerrit.named-data.net/c/NFD/+/7271 changes nfdc face create command defaults from persistent to permanent.
This is the first step of deprecating and removing persistent semantics.
Updated by Davide Pesavento 4 months ago
- Category set to Faces
I'd like to see a clear and comprehensive design before we move forward with any changes under this issue. The design should address the remaining outstanding questions in #4717 (which was closed prematurely IMHO).
Updated by Junxiao Shi 4 months ago
My plan is, progressively:
- nfdc defaults to creating permanent faces, but can still create persistent faces if requested.
- nfdc only creates permanent faces. This applies to all subcommands that could create faces.
- FaceMgmt deprecates persistent. Default persistency in ControlParameters becomes permanent.
- NFD interprets persistent as permanent.
- ndn-cxx deprecates persistent.
- ndn-cxx removes persistent. NFD rejects persistent
Updated by Davide Pesavento 3 months ago
I believe there are a few more unresolved design questions stemming from #4717, including:
- As pointed out in #4717#note-4, Unix faces resemble persistent faces in their behavior, although we currently classify them as on demand. If we want to fix this inconsistency in the future (as a separate issue), we may need a third persistency type. (though I admit I don't love the name "persistent" for this case)
- There may be some implications for
ndn-autoconfigthat haven't been fully fleshed out yet. (see #4717#note-3) - If permanent faces are expected to update their local IP address, which could change when the face reconnects, then someone needs to actually verify that this is indeed the behavior. If it's not, we need to fix the implementation.
- As a corollary, if the local IP changes, will the
LocalUrialso change? What are the implications of this?
- As a corollary, if the local IP changes, will the
- Another question I have personally: what's the relationship/difference with netdev-bound faces? (this may not be relevant here, but it's worth mentioning)
Updated by Junxiao Shi 3 months ago
As pointed out in #4717#note-4, Unix faces resemble persistent faces in their behavior, although we currently classify them as on demand. If we want to fix this inconsistency in the future (as a separate issue), we may need a third persistency type. (though I admit I don't love the name "persistent" for this case)
It's real simple: ondemand=incoming, permanent=outgoing.
Unix socket face would be ondemand always.
There may be some implications for
ndn-autoconfigthat haven't been fully fleshed out yet. (see #4717#note-3)
The autoconfig tool may choose to close old faces and open new ones.
If permanent faces are expected to update their local IP address, which could change when the face reconnects, then someone needs to actually verify that this is indeed the behavior. If it's not, we need to fix the implementation.
If device IP changes, the autoconfig tool can close old faces and open new ones.
As a corollary, if the local IP changes, will the
LocalUrialso change? What are the implications of this?
LocalUri contains local IP so that it must change.
Another question I have personally: what's the relationship/difference with netdev-bound faces? (this may not be relevant here, but it's worth mentioning)
There's no interest in implementing that.