Re: [PATCH 4/4] first conntrack ID must be 1 not 2

[Patrick McHardy <kaber@trash.net>]

Jozsef Kadlecsik wrote:
> On Fri, 31 Mar 2006, Patrick McHardy wrote:
> 
> 
>>>>Actually it would still not be unique if connections live
>>>>shorter than a jiffy and are resurrected.
>>>
>>>In which case would there be any harm in it not being unqiue, if it were
>>>the same connection resurrected, why try to avoid having the same id?
>>
>>Besides solving an implementation problem, so ID was meant as a
>>long-term unique identifier. For the life-time of a connection
>>the tuples are already a unique identifier.
>>
>>It's amazing, I've never had so many discussions about a single
>>32 bit field :)
> 
> 
> It's amazingly hard to accept we need it :-).
> 
> Putting aside the implementation problem, there are so many information
> already available in the conntrack entries: tuples, packet and byte
> counters, state, timeout value. Those together can serve as a short-term
> unique identifier, even after the entry is actually deleted. Not
> bulletproof, but in practice those can be sufficient.
> 
> I could not resist... :-))

Me neither :) I was just pointing out the idea behind the ID, not
necessarily condoning it. After discussing it with Rusty in Sevilla,
it became clear that we can provide guarantees similar to filesystems
without it, which seems to be good enough. So I have absolutely
nothing against removing it. In fact, IIRC the last discussion
stopped after I had sent a patch to remove it. I need to dig out that
patch again :)