Project

General

Profile

Actions
Copy link

Bug #2650

closed

FaceTable: FaceId collision

Added by Tai-Lin Chu almost 10 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
Forwarding
Target version:
v0.5
Start date:
Due date:
% Done:

0%

Estimated time:

Description

In the current implementation, it is possible to create a lot of faces, and force face id to collide.

Actions
Copy link
 #1

Updated by Junxiao Shi almost 10 years ago

  • Subject changed from [fw]face id collision to FaceTable: FaceId collision
  • Category set to Forwarding
  • Priority changed from Normal to Low

I acknowledge this Bug exists, but I don't see any urgency in fixing it.

FaceId is a typedef of int.
At the rate of 100 face creations per second, it takes 248 days to cause a FaceId collision.
By that time, new version of NFD is released, and the router is upgraded which requires an NFD restart.

When collision becomes a real problem in the future, a simple fix is to use int64_t so that it can last many years.

Don't attempt to reuse FaceId of closed Faces: RIB and routing daemon assumes FaceId are never reused.

Actions
Copy link
 #2

Updated by Tai-Lin Chu almost 10 years ago

In go-nfd, I tried to use face mem address as id, and a hash table to track valid faces.

I think this is faceId allocation is similar to malloc() in c, so I let OS do the work. Is it a good solution?

Actions
Copy link
 #3

Updated by Junxiao Shi almost 10 years ago

In go-nfd, I tried to use face mem address as id, and a hash table to track valid faces.

I think this is faceId allocation is similar to malloc() in c, so I let OS do the work. Is it a good solution?

No. This can generate same FaceId to a new Face after an old Face is destroyed, which violates the assumption in RIB and routing daemons:

Don't attempt to reuse FaceId of closed Faces: RIB and routing daemon assume FaceId are never reused.

Actions
Copy link
 #4

Updated by Davide Pesavento over 8 years ago

  • Start date deleted (03/16/2015)

FaceId is a typedef to uint64_t now. Shall we close this bug?

Actions
Copy link
 #5

Updated by Junxiao Shi over 8 years ago

  • Status changed from New to Rejected
  • Target version set to v0.5

This Bug is no longer a concern because FaceId has been changed to uint64_t during 2015 face refactoring.
It would take 584 years for FaceId to have a collision, at the rate of one new face per nanosecond.
I won't live to see that day.

Actions
Copy link

Also available in: Atom PDF