Question about Val serialization

Zeek
1

Master Robin,

I have a question about the serialization of vals (when serializing an
event call, for example). A bit of background: yesterday looked at
support for sending/receiving records in Broccoli. I got receiving
records working fairly quickly, and noticed that the serialization
protocol currently insists on sending the full serialized type of the
val it is sending (RemoteSerializer.cc, around 126):

  loop_over_list(*args, i) (*args)[i]->Serialize(this, true, info);
                                                       ^^^^
calling

  bool Val::Serialize(Serializer* s,
                      bool save_type,
                      const SerialInfo& info) const;

My question is, why is it necessary to send the full type details along
with the val, and not just an identifier of the type? It seems to me
that since types aren't really first-class data structures in the Bro
language (ie. no reflection etc) the remote Bro won't be able to do much
with the val if the script doesn't know the type already anyway?

I know the serialization caching mechanism you're using to stop sending
types repeatedly, but why is it *ever* necessary to send a type? Clearly
you had a reason in mind ...

I'm of course asking because ideally in Broccoli I'd like to be able to
send a record val just by saying what type of record it is and then just
send the list of values stored in the record.

So, is there any chance that sending the type along will be optional in
the new serialization protocol?

Thanks,
Christian.

2

My question is, why is it necessary to send the full type details along
with the val, and not just an identifier of the type? It seems to me

There are two main reasons:

- there isn't any direct assocation between types and identifiers;
while for a given id you can see whether it's a type, it doesn't
work the other way round: a type does not need to have a name (and
even if it has, it may be hard to get access to it).

- the value serialization is part of the larger picture which is
serializing a full Bro configuration. In this context a certain type
does not need to be known on the receiving side.

So, is there any chance that sending the type along will be optional in
the new serialization protocol?

Actually, I've now completely removed the possibility to send a
value w/o a type (as you have seen in the old code it was possible
given that the receiving side could deduce the type somehow). Given
the caching this works pretty good and makes things considerably
cleaner.

On the other hand, I can very well imagine a format in which,
alternatively, a type can be specified by a string (e.g. which would
then be looked up in the global ID space. Bro would probably not
sent something like this itself but receiving it from Broccolli
should be easy. So, the answer is yes. I'll add it.

Robin

3

[snipp!]

On the other hand, I can very well imagine a format in which,
alternatively, a type can be specified by a string (e.g. which would
then be looked up in the global ID space. Bro would probably not
sent something like this itself but receiving it from Broccolli
should be easy. So, the answer is yes. I'll add it.

Okay great but don't add it as special treatment just for Broccoli!
That'd make me feel bad :slight_smile:

Thanks for the details,
Christian.

4

Hi,Robin
For some reason,I want to get the MAC address info in the policy file,can U tell me how?
Regards!