Bug #3440
closed
RibManager: rib/register succeeds with non-existent face
100%
Description
Steps to reproduce:
- execute
nfd-status -fand make sure face 400 does not exist, and is not the next FaceId to be created nfdc register /org/openmhealth 400
Expected: 410 error
Actual: Successful in name registration: ControlParameters(Name: /org/openmhealth, FaceId: 400, Origin: 255, Cost: 0, Flags: 1, )
Files
Updated by Alex Afanasyev almost 9 years ago
- Subject changed from registering prefix on non-existing face returns success to Registering prefix on non-existing face returns success
- Category set to RIB
- Target version set to v0.5
- Start date deleted (
01/30/2016)
When we initially implemented this part, we didn't have FaceQuery command that is required to check existence of the supplied face id. Now we have it, and I think we should add the sanity check and avoid confusion.
Updated by Junxiao Shi almost 9 years ago
- File 1.pcap 1.pcap added
- Subject changed from Registering prefix on non-existing face returns success to RibManager: rib/register succeeds with non-existent face
- Description updated (diff)
- Assignee set to Vince Lehman
NFD Management protocol - RibMgmt specifies:
If face does not exist, the command fails with code 410.
This is a problem in RibManager rather than nfdc.
Attached tcpdump trace (obtained by setting transport=tcp4://127.0.0.1:6363 in client.conf then capture on lo interface) shows the response for rib/register command was 200.
I'm assigning this to Vince who implemented this command handler.
#2857 is in progress and will conflict with this fix.
The two assignees should coordinate with each other and decide in which order should the two issues be worked on.
Updated by
Updated by Junxiao Shi almost 8 years ago
- Target version changed from v0.5 to v0.6
NFD Management protocol - RibMgmt specifies:
If face does not exist, the command fails with code 410.
I realize that letting NFD-RIB fail a registration for non-existent face is not implementable: it may cause prefix registration errors on newly created faces. Consider this scenario:
- NFD receives a prefix registration command at the very first Interest that caused the creation of an on-demand face.
- A face event notification is generated when the on-demand face is created. NFD-RIB subscribes to this notification stream.
- The prefix registration command is sent to NFD-RIB.
Recall that forwarding does not guarantee in-order delivery. Thus, NFD-RIB may receive the face creation notification and the prefix registration command in any order. In case the registration arrives before the notification, NFD-RIB would perceive the face as non-existent.
Thus, I think the solution is:
- In RibMgmt,
rib/registershould succeed even if face does not exist. A successful response simply means the registration request is accepted. nfdc route addcommand should check the existence of face (when FaceId is specified) before invokingrib/registercommand.
Updated by Junxiao Shi over 7 years ago
- Status changed from New to Resolved
- Assignee set to Junxiao Shi
As explained in note-4, letting NFD-RIB fail a registration for non-existent face is not implementable.
410 error is deleted in RibMgmt r22.
nfdc register command is deprecated in favour of nfdc route add. nfdc route add behaves as specified in note-4:
vagrant@m0212:~/NFD$ nfdc route add /org/openmhealth 400
Face not found
vagrant@m0212:~/NFD$ echo $?
3
Updated by Junxiao Shi over 7 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100