Bug #3440
closed
RibManager: rib/register succeeds with non-existent face
Added by Haitao Zhang almost 9 years ago.
Updated over 7 years ago.
Description
Steps to reproduce:
- execute
nfd-status -f
and 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
- 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.
- 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.
- Assignee deleted (
Vince Lehman)
- 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/register
should succeed even if face does not exist. A successful response simply means the registration request is accepted.
nfdc route add
command should check the existence of face (when FaceId is specified) before invoking rib/register
command.
- 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
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF