From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 4/4] first conntrack ID must be 1 not 2 Date: Fri, 31 Mar 2006 20:44:56 +0200 Message-ID: <442D78A8.4050300@trash.net> References: <43EFF1F0.1090701@netfilter.org> <20060213112028.GU4601@sunbeam.de.gnumonks.org> <43F438F5.8070607@trash.net> <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harald Welte , Pablo Neira Ayuso , Netfilter Development Mailinglist , Amin Azez , Yasuyuki Kozakai Return-path: To: Jozsef Kadlecsik In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org 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 :)