Re: conntrack session information

[Wang Jian <lark@linux.net.cn>]

Hi Amin Azez,

It is most easy to use an unique id which will not wrap for quite
sometime, but I think the overhead (size) is too much.

The alternative way to do it is just adding protocol information to
every event message, so the tuple of conntrack is complete. The tuple
will not duplicate during its lifetime, am I wrong? This is enough to
build up the whole session. I assume that two conntracks using the same
tuple are always perfect serialized, in the NEW, DESTROY, NEW, DESTROY
order, not in NEW, NEW, DESTROY, DESTORY order.

If you are using a sql database to store the session, it is easy. If you
are not using sql database, you have to do a little more work but not
big deal.

The tricky issue when building session is that DESTORY message gets lost.
This troubles unique id way as well as tuple way.

On Wed, 20 Apr 2005 13:11:14 +0100, Amin Azez <azez@ufomechanic.net> wrote:

> 
> Wang Jian wrote:
> > There is problem to create whole sessions record from events. event
> > messages should carry necessary information for correlation
> 
> I'm proposing that we base this session id on a 64 bit counter.
> I will also want to adjust conntrack to record the system time at which 
> the conntrack was created anyway.
> 
> If we also associate with this a serial number, the chances "in normal 
> use" that the counter will wrap around with the same system time are 
> miniscule.
> 
> For most purposes the connection serial number is unique, but the 
> associated timestamp makes it historically unique.
> 
> Final question, I suppose that ip_conntrack.master references will cause 
> the master conntrack (of related conntracks) to hang around until the 
> related conntracks have been deleted? Thus, the netlink stuff can report 
> the id of the master conntrack when it reports other conntrack info.
> 
> Does this sound reasonable to folk? Is this too much overheard per 
> conntrack? What bottlenecks are there?
> 
> Maybe it would require a cross-cpu counter with serialized access. Is 
> there a standard kernel form for this, or do we use spinlocked structs 
> or something? Or is a per-cpu counter preferred, combined with a CPU-id?
> 
> Amin
> 



-- 
  lark