[Bro-Dev] Updating / Accessing ConnVal from child analyzers

[Gregor Maier]

> Here's another idea:
> 
>     - move UpdateEndpointVal() from TransportAnalyzer to Analyzer
> 
>     - have BuildConnVal() iterate over the analyzer tree and call
>       *every* analyzer's UpdateEndpointVal. Doing so gives all
>       analyzers the chance to update the value as appropiate, with
>       most often just doing nothing. In principle, there could be
>       conflicts with multiple analyzers updating the same fields,
>       but in practice that shouldn't happen and we can just declare
>       that situation as "undefined".
> 
> This adds a tiny bit of overhead but my guess is that it would be
> quite a bit less noticable (if at all) than updating the counters
> with every packet.

I really think that the overhead should be small. After all, you have to
call DeliverPacket/DeliverStream on every *packet*, but
UpdateEndpointVal() only whenever an event is generated.

> What do you think?

If we do that, we should probably generalize this, so that Analyzers can
update the full ConnVal record and not just the endpoints. Afterall, it
might well be the case that analyzers want to store some information
that's for the connection as a whole and not just one side of the
connection. So instead of of UpdateEndpointVal, we could have an:
  UpdateConnVal (RecordVal *connval,
         RecordVal *orig_endp, RecordVal *resp_endp)

(note that the endpoint val would also be accessible by extracting them
from the connval, but I think this is easier).

One disadvantage is now, that analyzers can change the actual ConnVal,
including starttime. (OTOH, they can also change the services set).
Plus, analyzers should not change the pointers to the endpoints that are
stored in the connval.

What we could do though is to add an additional RecordVal to ConnVal,
that analyzers can overwrite:
type connection: record {
    id: conn_id;
    orig: endpoint;
    resp: endpoint;
    start_time: time;
    duration: interval;
    service: string_set;    # if empty, service hasn't been determined
    addl: string;
    hot: count;     # how hot; 0 = don't know or not hot
    history: string;
    foo: conn_addl &optional;
};

type foo_addl: record {
   bar: string &optional;
}

Then we could have an
   UpdateConnVal (RecordVal *foo_addl,
         RecordVal *orig_endp, RecordVal *resp_endp)


(We could then even move the "history" field into the optional foo_addl,
since it's often not set. This might save some memory.)
(I actually wanted to name the additional foo field in connection addl,
but unfortunately this name is already taken :-( )


What do you think about that?


cu
Gregor
-- 
Gregor Maier                                             gregor at icir.org
Int. Computer Science Institute (ICSI)          gregor at icsi.berkeley.edu
1947 Center St., Ste. 600                    http://www.icir.org/gregor/
Berkeley, CA 94704
USA