Need help understanding serializer

[Christian Kreibich]

Hi!

On Tue, 2004-04-27 at 10:16, Robin Sommer wrote:
> On Mon, Apr 26, 2004 at 12:27 -0700, Christian Kreibich wrote:
> 
> >   bool Serialize(Serializer* s) const;
> >   bool Serialize(Serializer* s, SerialInfo* i, bool cache = true) const;
> 
> Good point. The difference is that you don't call
> SerialObj::Serialize() directly but Conn::Serialize() which, in
> turn, uses SerialObj::Serialize() to do its work; i.e.
> SerialObj::Serialize() does not really belong to the user-interface.

All is clear :)

> > ...). How do I get from the Serializer at the receiving end noticing
> > that something arrives, to the Bar::Unserialize() call at the far end?
> 
> If I understand your question correctly, you're expecting some
> call-back mechanism, right?

Yup sort of. I guess my problem was that I approached the thing with a
different idea in mind how it would work. 

> That's not the case here. The receiving
> Serializer sees that one of the basic entities (i.e. those with
> character constants) has arrived. Then it will call the
> corresponding Unserialize() method. If that is, e.g., a Connection,
> then Connection::Unserialize() is called. If the connection contains
> a Foo object, Connection::DoUnserialize() will call
> Bar::Unserialize().

Ah I think I'm getting there. You're using a callback mechanism for the
basic entities only, and then the DoSerialize/DoUnserialize API to
handle the objects referenced by the basic entities.

> > Bro-Bro specific stuff? And let the toplevel Serializer be a very
> > bare-bones interface that only lets you read/write primitives (ie the
> > various Read/Write methods)?
> 
> In general, adding an extra step would be fine with me. But I am not
> sure if I got your idea right. Do you indeed want to access only the
> Read/Write methods (not any of the Serialize/Unserialize)? If yes,
> perhaps the SerializationFormat itself would suffice?

Well see I need a mechanism to communicate with local sensors (in
intrusion detection parlance), and I was thinking of communicating
through unix domain sockets (largely because I have code that I could
reuse for that). So at the Bro end, another Serializer sounds like a
good idea.

The problem is that the existing Serializer class already implies that I
want to send connections, IDs, etc (ie things that are largely
interesting for Bro-Bro communication only) which is not necessarily the
case for what I need. The SerializationFormat gives me what I need to do
the marshalling, but it doesn't handle I/O. And a format plus I/O are
pretty much the core ingredients of a Serializer, right? Also I could
build the callback API that I was looking for in my own Serializer...

Thanks,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org