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