Changes between Version 4 and Version 5 of soc2009


Ignore:
Timestamp:
Mar 18, 2009, 8:29:16 PM (14 years ago)
Author:
viboes
Comment:

Adding Frames

Legend:

Unmodified
Added
Removed
Modified
  • soc2009

    v4 v5  
    5555
    5656[http://groups.google.com/group/boost-list/browse_frm/thread/df6ecfb0089b28fd]
     57
     58== Serialization/Frames  ==
     59
     60Library based on an extension of the Archive concept making it bidirectional.
     61 
     62From wikipedia "A frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames."
     63
     64The Boost.serialization saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the beginning of the archive.
     65The saving frame concept will allows to save serializable data either at the end or the '''begin''' of the frame, and the loading frame concept allows to read serializable data from the beginning or the end of the archive.
     66 
     67I'm not sure which syntax will be the more appropriated. The serialization library use the <<, >>, and & operators that are associative from left to right. We need the equivalent operators from right to left. <<=, >>=, and &= seams to be the more natural candidates but I don't know if it is correct in C++ to define this operators with this prototype
     68
     69{{{
     70#!cpp
     71template <typename T> frame& operator<<=(const T&, frame&);
     72template <typename T> frame& operator>>=(const T&, frame&);
     73template <typename T> frame& operator&=(const T&, frame&);
     74}}}
     75
     76{{{
     77#!cpp
     78h1 >>= h2 >>= sf << t2 << t1
     79}}}
     80
     81is equivalent to
     82
     83{{{
     84#!cpp
     85(h1 >>= (h2 >>= ((sf << t2) << t1)))
     86}}}
     87
     88and should be equivalent to
     89
     90{{{
     91#!cpp
     92sa & h1 & h2 & t2 & t1
     93}}}
     94
     95if sf and sa were empty.
     96
     97The main difference is that we can do it hierarchically. The top layer will create a frame, and serialize its own information elements.
     98
     99{{{
     100#!cpp
     101frame sf;
     102h_n >>= sf  << p_n << t_n;
     103}}}
     104
     105Then this top layer will use a primitive of the lower level having as parameter the frame as payload.
     106{{{
     107#!cpp
     108primitive_n-1(sf);
     109}}}
     110
     111A primitive at the k level will add its own header and trailer information element to the payload of the upper level
     112
     113{{{
     114#!cpp
     115void primitive_k(frame& sf) {
     116    // ...
     117    h_k >>= sf  << t_k;
     118    // ...
     119    another_primitive_k_1(sf);
     120    // ...
     121}
     122}}}
     123
     124So the frame allows to serialize top-down. To get the same result with the archive concept the serialization must be done bottom-up, needing to chain each one of the information element in a list and only when we have all off them we can start the serialization.
     125I think that the frame approach should be more efficient because it avoid to store in dynamic memory the information elements to be serialized, instead they are serialized directly.
     126
     127Loading a frame works as loading an archive, except that we can load also at the end of the frame. This avoids to load the complete archive to load the trailer of the lower levels.
     128
     129{{{
     130#!cpp
     131lf >>= h_1;
     132// ...
     133t_1 << lf;
     134}}}
     135
     136In addition, it would be great to have saving/loading frames (I'm not sure but I think that an archive can not be saving and loading at the same time). The same frame can be used as loading, analyzing only some lower levels, and as saving in order to construct other lower levels. This will be very useful for gateways and routers.
     137
     138{{{
     139| L4 |<------------------------------>| L4 |
     140| L3 |    |     ADAPTATION     |      | L3 |
     141| L2 |<-->| L2 |          | X2 | <--> | X2 |
     142| L1 |<-->| L1 |          | X1 | <--> | X1 |
     143}}}
     144
     145It would be great also that the same data that can be serialized on archives, could be serializable on a frame using the same save function. But this works only when we save at the end of the frame. Let me see this using a
     146little example: Class C has 3 information elements to serialize (a, b and c). So the save
     147functions could be something like
     148
     149{{{
     150#!cpp
     151template <typename ARCHIVE>
     152void C::save(ARCHIVE& sa) {
     153    sa & a & b & c;
     154}
     155}}}
     156
     157This save function works well from left to right, but can not be used when saving at the beginning of a frame, because the expected result when saving at the beginning is
     158
     159    || a || b || c || sa ||
     160
     161but the result will be
     162
     163    || c || b || a || sa ||
     164
     165So unfortunately we need a different save function
     166
     167{{{
     168#!cpp
     169template <typename FRAME>
     170void C::save(FRAME& sa, begin_tag&) {
     171    a >>=  b >>= c >>= sa;
     172    // a >>=  (b >>= (c >>= sa));
     173}
     174}}}
     175
     176