From: Scott Woods (scottw_at_[hidden])
Date: 2004-12-29 14:55:17
----- Original Message -----
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
Sent: Wednesday, December 29, 2004 7:40 PM
Subject: [boost] Re: Re: Serialization and async messaging
> > Assume an object whose serialization is something like 4K. If reading
> > from a file, or even a TCP stream with the socket in blocking mode, then
> > you just keep reading until you get all the data. However, for a socket
> > in non-blocking mode, you will typically use select or poll or some
> > other notification mechanism to be told when data is available. You
> > will then go read as much as is currently available, and then return to
> > other tasks until more data is ready. Let's say that data is slow, and
> > to ready the entire 4K of data, it takes 10 different "notifications"
> > and 10 different "read" operations.
> I don't think this is that big of a problem. This is usual situation in
> marshaling implementation that parser/builder/marshaler class need to have
> completed data block. And the usual solution is to use some kind of
> level envelope that allows detect end. So what you do is you collect you
> pieces in buffer and then process it altogether. This is a case whether
> sending object by object or (most probably) whole I don't know ...
> In all practical cases it does not incur any significant time/space
> (IOW buffer size, envelope and message units could be configured so it's
Understand this and can envision a successful implementation. It would
seem to involve some duplication though, i.e. the generation and detection
of the envelopes is similar to what occurs in serialization already. It was
this duplication of (apparently equivalent) code that I was hoping to avoid
in the first place.
If the serialization format (e.g. XML) already satisfies your requirement
"some kind of protocol level envelope that allows detect end" then it
seem a little tragic to ignore that potential? OTOH the envelope technique
can be applied to all sorts of things and that might be enough to satisfy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk