Would it make more sense to store this value in the connection record directly? It doesn't really add any information to the conn_id over the existing fields and I suppose it would make comparison operators take a bit longer. However, it would make the logging framework integration really easy that way you have it.
.Seth
Yeah, I was wondering where to put it, and I'm still undecided.
I suppose it would make comparison operators take a bit longer.
Haven't thought about that but could we now change them to use the new
uid?
However, it would make the logging framework integration really easy
that way you have it.
That's exactly why for now I went with the conn_id. That way, whoever
logs the id, will automatically log the unique string as well, which
is neat.
Robin
I suppose it would make comparison operators take a bit longer.
Haven't thought about that but could we now change them to use the new
uid?
I guess direct comparisons aren't really done that frequently, but table and set lookups are done all the time. Would it affect table and set lookups to have the extra string to compare? It shouldn't affect lookup time much (or any) should it?
That's exactly why for now I went with the conn_id. That way, whoever
logs the id, will automatically log the unique string as well, which
is neat.
It also gives us the option for changing the default filter to remove either the 4-tuple or the unique string so that sites could choose globally what shows up in their logs if they are just running the default filters.
.Seth
I guess direct comparisons aren't really done that frequently, but
table and set lookups are done all the time. Would it affect table
and set lookups to have the extra string to compare?
One could now actually use the uid as the table index ... However,
that wouldn't be as intuitive as using the whole conn_id and I don't
think I want to advocate that.
However, here's disruptive alternative: we could move
{orig,resp}{_h,_p} into the connection record and then use the unique
identifier as the "id" directly ... (Wouldn't do the automatic logging
of both though).
It shouldn't affect lookup time much (or any) should it?
It could a little bit but nothing signficant I'd guess (but always
hard to say).
It also gives us the option for changing the default filter to remove
either the 4-tuple or the unique string so that sites could choose
globally what shows up in their logs if they are just running the
default filters.
Assuming fields are named consistenly, that would also work if the uid
were explicitly inlcuded into the log record.
So, I'm fine going either way, conn_id or connection.
Robin
One could now actually use the uid as the table index ... However,
that wouldn't be as intuitive as using the whole conn_id and I don't
think I want to advocate that.
Ok.
However, here's disruptive alternative: we could move
{orig,resp}{_h,_p} into the connection record and then use the unique
identifier as the "id" directly ... (Wouldn't do the automatic logging
of both though).
Going the other direction, how about we put the uid in the connection record? We'd then have c$uid and c$id. That causes the least amount of mental and code disruption while accomplishing essentially the same thing.
Assuming fields are named consistenly, that would also work if the uid
were explicitly inlcuded into the log record.
I need to think more about how this could be used as seamlessly as possible with the logging framework, I don't have a good idea yet.
.Seth