Bug #2650
closed
FaceTable: FaceId collision
Added by Tai-Lin Chu over 9 years ago.
Updated about 8 years ago.
Description
In the current implementation, it is possible to create a lot of faces, and force face id to collide.
- 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.
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?
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.
- Start date deleted (
03/16/2015)
FaceId is a typedef to uint64_t now. Shall we close this bug?
- 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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by