----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> 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.