Scott Woods wrote:
transmitting program ============== serialize to a string. we now have its total length. transmit a string using what ever method syncronous/asyncronous whatever.
recieving program ============ retrieve a string - using what ever method async, sync or whatever. when a complete string is retrieved/reassembled or whatever de-serialize to the original structure.
Honestly, I can't see any thing about this that is less than optimal.
Aha. After Gennadiy's version of this I can now see it for what it is.
Yes, the simple response is that this will work. A pedantic response is that it feels like duplication; why implement another layer (the envelopes) just to detect completion of objects, ignoring the potential in the existing serialization format (e.g. XML). A more useful response would point out the higher memory requirements, two scanning phases and increased incidence of copying.
If you're really a gluton for punishment consider the following: make you sockets/tcp/whatever implementation with a i/ostream interface. E.G. class socket_istream ... Transmit ====== { //opens a socket_ostream socket_osteram os(???); // all current archive classes use a basic stream interface. so { xml_oarchive oa(os); // start serializing oa << ... ... // stop serializing ! } } Recieve ===== { //open and input socket stream socket_istream is(???); // all current archves classes use basic stream interface - so { xml_iarchive ia(is) ia >> ... ... // done } } Let us know when you've got this working. Good Luck Robert Ramey