$tag in notice_info

Development
21

Sure, but I was trying to avoid the MD5 altogether.

Robin

22

Whoops, you're right. I was thinking it would be done for each connection for some reason.

.Seth

23

I was wondering about that too and the answer is: I don't know ... I
was looking for a hash that is cheap to calculate, don't really want
to do an MD5 per connection. Other suggestions?

Robin

24

I was wondering about that too and the answer is: I don't know ... I
was looking for a hash that is cheap to calculate, don't really want
to do an MD5 per connection. Other suggestions?

I think a universal hash should work here. There's already one in Hash.cc,
thanks to Ruoming (I think) and avoiding algorithmic complexity attacks.

    Vern

25

Good idea!

Robin

26

I've added code implementing the unique connection identifiers in a
topic branch. However, two questions:

- There are actually a number of hash algorithms in Hash.{h,cc}, with
only one of them being used (via #ifdefs). Vern, do you remember the
story behind having multiple of them, and can we just remove the code
for those not enabled?

- I'm wondering whether for the unique connection ids it would make
sense to make them stable in the case that we're working offline from
a trace. It kind of bothers me that when reading the same trace
multiple times, I get a different output each time. Should we just
fix the instance ID when reading from a trace?

Robin

27

- There are actually a number of hash algorithms in Hash.{h,cc}, with
only one of them being used (via #ifdefs). Vern, do you remember the
story behind having multiple of them

I'm pretty sure that Ruoming (or maybe even Yin Zhang, come to think of it)
had several so he could do performance testing across them.

and can we just remove the code for those not enabled?

Yeah, though hopefully we'll remember that we have them buried in
the repository if at some point we find ourselves wanting to play
with hash functions again.

- I'm wondering whether for the unique connection ids it would make
sense to make them stable in the case that we're working offline from
a trace.

I would definitely like that!

    Vern

28

What I've now done is making them stable if a hash seed is provided.
That seems in line with how things are currently: when running from a
trace results are non-deterministic by default, but seeding gets rid
of that.

Robin

29

You could also use the first packet's timestamp and/or a hash over it's
content + hostname or such to generate the 64bit run-ID. This way we
would always get consistent behavior even if no seed is sets.....

but ymmv
gregor