[Boost-users] boost.serialization, asio and iostreams...

Subject: [Boost-users] boost.serialization, asio and iostreams...
From: Hajo Kirchhoff (mailinglists_at_[hidden])
Date: 2009-03-03 15:06:45

(forwarded from asio.user as serialization questions might be more
appropriate here)

Hi all,
I plan to use serialization and asio together to exchange 'command
objects' between two applications. Basically marshalling an object and
sending it to a remote application.

There is a simple asio example using serialization, but there are two
issues I'd like to improve.

[1] I am concerned about performance. The example constructs and
destructs an archive for every single object and uses stringstream,
which creates and copies a string object.

Wouldn't using asio::tcp::iostreams give better performance?

and
[2]: I would like to utilize the boost.serialize class registration
system to allow peer programmers to create new objects. In the example I
would need to send a 'type' and the size manually in a 'header' before I
serialize and send the actual object. That would require a system wide
enumeration or other 'type' mechanism.

My idea is to require all objects be derived from a common polymorphic
base and then serialize a pointer to the object. The archive would
serialize the entire object and also send type information with it, so
the receiver could reconstruct the object simply by receiving a pointer.

class basic_command;
class my_command:public basic_command;

On the senders side:
my_command dosomething;
archive << &dosomething;

On the receiver side:
basic_command *next_command;
archive >> next_command;
next_command->execute();

This would have the benefit that new commands could simply be created by
deriving from basic_command. It might also have performance consequences
and I have one specific question:

For this in order to work I would need to disable tracking for
'my_command'. Otherwise only the very first instance of archive <<
&dosomething would actually send something.

Question: Can I 'reset' the binary archive such that the tracking
information is reset, but not the type information? Or can I temporarily
disable tracking for a class or for the next save/load operation?

I don't want to globally disable tracking for my_command, because I
cannot rule out that someone might actually want tracking for their
object in a different archive (such as saving settings to disk).

I'd love to hear from you and any comments are welcome. Has anyone
already done this? What are your experiences?

Regards

Hajo