[Bro-Dev] serialization problems

[Robin Sommer]

> After enabling the serialization debug logs, I think what I'm seeing
> is that the first event is serialized with the full table value, but
> the second event is serialized with just a reference to the first's
> even though that value has changed.

Yes, that's exactly what's happening. Generally, the serialization
framework sends an object only the first time, and from then on sends
just references to it (i.e., unique IDs).

While for your example this is not ideal, it's a trade-off with three
other objectives: (1) keeping the volume manageable (always sending
everything would quickly become a lot; and it's actually not easy to
find what has changed since last time); (2) maintaining correct
references where they are needed (think about two record types A and B
both having a subfield of record type C; now separate instances of A
and B can reference the *same* instance of C, and if we send A and B
to a peer, that structure needs to be recreated over there); and (3)
making this all work with remote peers that come and go during
run-time as they please ...

Also, the use-case you describe is rare in actual Bro scripts: it
involves a single record instance that's passed into two events and
modified in between. (Well, I *believe* it's still rare; with scripts
getting more complex these days, that may be changing ...).

And note that for Bro-to-Bro communication, record modifications are
normally covered by using &synchronized. For that, state operations
are send across the channel and then replayed on the other side to
reflect the update.

This whole sending-object-IDs around is, btw, also the reason why we
can't do real broadcasts ...

Robin

-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org