Re: [Boost-users] [statechart] [spirit] OSI delimited message framing

Subject: Re: [Boost-users] [statechart] [spirit] OSI delimited message framing
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-06-19 14:08:29

Thank y'all for the feedback.

Will probably go with some sort of context for a byte-wise unwrap
operation (decouples from whatever read source), and spits out a smart
pointer next message when it can be unwrapped.

I gather here, bind to whatever stateful context handler needs to be
used for the next character. Simple enough.

For the wrapping side of things, I'd like to go with karma if I can.
The wrapping sequence is one layer in the OSI layer 7 protocol.
Loosely coupled from whatever message payloading.

SOM and EOM sequences are straightforward enough. However, I am
unclear how to conditionally generate the next byte in the sequence.
In other words, would be either the next byte as-is, or an escape
delimited byte. Loosely:

typedef std::vector<uint8_t> buffer_type;
byte next_ = some_value;
karma::rule<buffer_type::iterator> dle_ %= next_ | ( byte_(m_dle) << next_ );

However, how to tell karma what the condition is?

On Wed, Jun 19, 2013 at 12:27 PM, Michael Caisse
<mcaisse-lists_at_[hidden]> wrote:
> On 06/19/2013 04:55 AM, Michael Powell wrote:
>> Hello,
>>
>> I need to design a delimited message framing for TCP/IP sockets,
>> probably using Asio to facilitate transport. Then build an OSI layer 7
>> application vernier to handle framing.
>>
>> I've dabbled a bit with Spirit and cooked up a couple of "simple"
>> micro grammars throughout the code base. In a sense, I could see a
>> delimited message framing strategy being a grammar of sorts, but this
>> seems somewhat complex for a grammar to handle when you consider the
>> overhead of verifying pass/fail (message or not a message), plus
>> extracting the message within the delimiters.
>>
>> Or, more likely approach the problem with statechart in mind. I've
>> dealt with framed messages in the past more like this. One state is
>> the escape byte, which can be followed by SOM, EOM, or another
>> true-escape-byte (intended message byte). Plus other fields like
>> message type, sub-type, how to handle payload, arguments, and so
>> forth.
>>
>> Anyone else dealt with things like this before? With Spirit? With Statechart?
>>
>
> Hi Michael -
>
> We write a lot of communication layers for both internal and client use.
>
> One approach is to use use Spirit Qi/Karma to act as a translator. It
> takes data objects in and produces byte streams (Karma) or takes a byte
> stream in and produces objects (Qi). We use Asio for the communication
> layer and Spirit for the protocol layer. This can all be nicely wrapped
> up in a generic objects.
>
> Spirit is stack based and so interrupting mid stream and saving state
> when partial messages are received can be tricky. The *answer* is to use
> a coroutine (Boost.Context).
>
> We have also used a statemachine approach but prefer to use MSM for
> protocol machines. It is much faster.
>
> Just to add a bit more to the discussion:
>
>    message =
>          omit[ *( !som >> byte_ ) ]     // sync stream to start of msg
>      >>  som                            // start of msg rule
>      >>  *( byte_ - eom )               // put your rule here
>      >>  eom                            // read end of msg
>      ;
>
>
> The version above could synthesize a std::vector<unit8_t> for example.
> You could have it parse the various message types or some generic
> structure (16-bit command followed by N-byte payload).
>
>
> I hope this gives you some thoughts.
> michael
>
> --
> Michael Caisse
> ciere consulting
> ciere.com
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users