From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: ctnetlink questions Date: Mon, 20 Oct 2003 20:53:08 +0200 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <3F942F14.8070505@trash.net> References: <20031020144842.GK4914@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jozsef Kadlecsik , Henrik Nordstrom , Netfilter Development Mailinglist Return-path: To: Harald Welte In-Reply-To: <20031020144842.GK4914@sunbeam.de.gnumonks.org> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org Harald Welte wrote: >1) uniquely representing ip_conntrack during state replication between >master and slave. Here the tuple is sufficient, since all state changes >will be processed in-order. Since the tuple is always unique in the >hashtable, there is no mistake of updating/deleting the wrong one. > >2) uniquely identifying an ip_conntrcak from userspace. >When userspace first dumps and then deletes by tuple, the tuple might >already have been reused. This is what most of the discussion was >about, where a 64bit counter or the generation counter+address had been >suggested as possible solutions. > > Seems now I didn't understand. How can we use the ids generated by a generation counter in userspace ? In any busy system they will be invalidated too fast .. Best regards, Patrick