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