# \[Bro-Commits\] \[git/bro\] topic/robin/conn-ids: Extending conn\_id with a globally unique identifiers. (881071c) **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [March 16, 2011, 11:28am UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832 "2011-03-16T11:28:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [March 16, 2011, 11:28am UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832/1 "2011-03-16T11:28:18Z")
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 ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [March 16, 2011, 3:25pm UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832/2 "2011-03-16T15:25:06Z")
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 ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [March 16, 2011, 4:02pm UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832/3 "2011-03-16T16:02:30Z")
> > 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 ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [March 16, 2011, 4:32pm UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832/4 "2011-03-16T16:32:13Z")
> 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 ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [March 16, 2011, 4:45pm UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832/5 "2011-03-16T16:45:26Z")
> 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 ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:39pm UTC](https://community.zeek.org/t/bro-commits-git-bro-topic-robin-conn-ids-extending-conn-id-with-a-globally-unique-identifiers-881071c/1832/6 "2022-05-06T15:39:29Z")
Closed on May 6, 2022, 3:39pm UTC