On Fri, Dec 10, 2010 at 11:06 -0800, you wrote:
We can probably keep a 64 bit counter internally and
also add a
bro_instance_ID, that's globally unique across Bro runs. For logging, we
can then log the 64 bit counter and the instance_ID, or concatenate the
two (I would guess that the instance_ID will be handy in other
situations too). Doesn't the cluster already have/need something like that?
There's a global peer_description (string) that if set will be used
as prefix for IDs in logs; see prefixed_id() in bro.init. The
cluster sets that differently for each a node.
However, the cluster currently also doesn't give unique IDs across
runs, just unique across nodes within a single run).
In order to generate such an instance_ID, we could:
My main concern is not wasting too many bytes for these IDs, as I
imagine they would be included in pretty much every log entry. On
the other hand, I don't think we need to be 100% sure that the IDs
are unique as long as the probability of a collision is small. Seems
that a single 64-bit int should be able to achieve that already if
we hash all information in.
b) the user supplies a "hostID", we can then
add time and PID
and hash all that together to get the instance ID, e.g.,
md5(hostID + PID + gettimeofday())
I generally like this, and the hostID can be the peer_description.
But I think we can hash into 64-bit instead and probably take a
simpler hash function as well. And then we can just add the 64-bit
counter to that value.
Robin Sommer * Phone +1 (510) 722-6541 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org