Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-12-29 00:02:37


Scott Woods wrote:
> Hi,
>
> I have been doing a lot of async messaging over TCP and have looked
> through the serialization library in the hope that it could be
> applied to the task.
>
> If the serialized representation of an object has an unknown length
> then its reasonable to say that we dont know how many network
> blocks will be consumed, i.e. the receiver may read 1 or more blocks
> before completion. We also cant guarantee that the flurry of recv's
> that might result from an FD_READ (sorry to those non-Windows folks),
> will neatly terminate on an object boundary.
>
> IMHO the input function (operator>>) needs to be "re-entrant" if
> serialization can be used in an async environment. Repeated calls
> should be perfectly acceptable. Ultimately it would return an
> indication
> that a complete object has indeed been loaded. Some "state" needs to
> be held somewhere. My best guess is that this is not the case but I
> cant
> find anything conclusive (without wading deeper into code).
>
> Can anyone comment?
>

I'm not sure I'm understanding exactly what you want to do - but that deters
me not at all from making a comment.

I envisioned the library would be useful for marshalling data accross space
(transmitting/recieving between programs) as well as across time
(persistence - the most common application). So I would be pleased to see
someone apply it in this way.

However, I don't think the concept of transmission protocal should be mixed
into the library - which is already very complex.

I believe you could easily achive what you want to accomplish by
serializaiton to a memory buffer (e.g string_stream) and transmitting this.
On the other end the inverse of this process would occur.

Robert Ramey

> ps:
> Its a thoroughly amazing library.
>

Have you concluded this from actually using the library or from just reading
the documentation?

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk