[erlang-questions] gen_fsm to parse binary protocol frames

Alex Arnon <>
Wed Aug 4 14:04:18 CEST 2010


I think that indeed for handling protocol endpoints, using gen_server or a
handcrafted process is common.


On Wed, Aug 4, 2010 at 1:09 AM, Andre Nathan <> wrote:

> Hello
>
> I'm dealing with a simple protocol whose frames consist of a fixed-size
> header, which contains a length field which specifies the size of the
> message following it.
>
> I implemented a gen_fsm to handle this, using two states,
> assemble_header and assemble_message. Each state responds to a 'data'
> event whenever new data arrives from a socket (this data is sent from a
> separate gen_server process). The assemble_header state responds to the
> header_complete event switching to assemble_message, and
> assemble_message responds to a message_complete event by starting
> message processing.
>
> My problem is the following. Since data comes from a socket, I don't
> have control of how much data is read. It's possible, then, that a whole
> frame (or more) has been already buffered when it's sent to the FSM.
> This would cause the FSM to parse the header and switch to the
> assemble_message state, but there will be no more messages to trigger
> the 'data' event, since the whole frame has already been sent.
>
> To solve this, I'm doing calling assemble_message({data, Rest}, State)
> directly from the assemble_header state when this situation is detected.
> That is, I'm forcing a state switch and triggering an event so that the
> data I've already received can be processed. This feels kinda ugly...
>
> So my question is, is the gen_fsm the preferred way to do this kind of
> thing? If so, is there a cleaner solution to the problem which wouldn't
> require the gen_server which feeds the data to the gen_fsm to know about
> the protocol message format?
>
> >From a little discussion on IRC, it seems that doing this processing in
> the gen_server process would be a simpler solution. Is this what people
> generally do?
>
> Thanks in advance,
> Andre
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
>
>


More information about the erlang-questions mailing list