Re: [RFC] alternative to conntrack ID

[Patrick McHardy <kaber@trash.net>]

Amin Azez wrote:

> It is entirely possible that a new conntrack with the same tuples is
> created before the user program can be aware the old one has been
> destroyed.
> 
> Defining multiple successive connections as "one flow" is convenient,
> but as user space clients are notified of "interuptions and
> restorations" to this "one flow", it would be also convenient if they
> could safely take advantage of such notifications.

Agreed. Besides, this is an interface to conntrack, not flowtrack :)

> If an ID is not desirable as part of the tuple (and I can see that it is
> not) perhaps a "created time-stamp" per conntrack would suffice as an
> extra "guard" which MAY be provided to conntrack manipulation routines,
> and if so provided MUST also be satisified for the operation to take place.
> 
> That is my suggestion. It does not introduce an alternative ID, it does
> avoid the problem of race conditions.
> 
> Comments?

Why is that better than a unique ID? It needs space as well, but can't
be used to identify the conntrack without further information.

Regards
Patrick