Re: [boost] Re: Re: Serialization and async messaging

From: Scott Woods (scottw_at_[hidden])
Date: 2004-12-29 14:21:40

----- Original Message -----
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 29, 2004 7:16 PM
Subject: [boost] Re: Re: Serialization and async messaging

<snip>

> > I could be missing the boat, but this is the usual problem with
> > serialization methods, when using them with sockets.  For this to
> > work,
> > the operator>>() has to know that there is no more data (i.e.,
> > correctly interpret return code of read when the fd is in
> > non-blocking mode), and
> > keep its current state so that the next call to operator>>() will
> > continue where the last call left off.
> >
> >
> > I do not see this as a protocol issue but as supporting non blocking
> > reads where you can get the data in many small chunks.
> >
> >
> > Then again, it is possible that the serialization library already does
> > support this in some way...
>
> Not as far as I can see.  I would say that one should serialize the data
in
> the chunk size you want and not attempt to break up the chunks.
>

Hmmmm. My background in network messaging gives me a certain
POV and now I can see that serialization (a la persistence) gives quite
another.

Any attempts to arrange "chunks" at the level we are talking about
will be subverted by the network (some router somewhere will decide
to fragment/coalesce/...). So we can never give significance to a block
received, i.e. the first byte may not be the first byte of a serialized
object and the last byte may not be the last byte of a serialized object.

Thanks for the feedback. My original question was fairly "open" (not
deeply researched ;-) I suspected that operator>> was not really going
to be appropriate in an async environment but held out some hope
that experts would have found a completely different way to apply
your library.

Scott.