[erlang-questions] tcp data in a gen_fsm

[Ingela Andin]

Hi!

2015-11-30 8:42 GMT+01:00 Benoit Chesneau <bchesneau@REDACTED>:

> isn't the ssl module using a gen_fsm?
>
>
Sort of! The protocol of course fits the FSM-principal and the states helps
understanding the code.  But the state functions are called by a local
dispatch function as all events so to speak are recived on the socket. We
thought of sending a message to ourselfs, but that does not really work out
as data recived on the socket may need to be treated diffrently due to data
received just before, and then sending a message to ourselfs may cause the
data
that need to be handled in the new way to be recived before the event that
changes the state telling us how to treat the new data. We are actually
looking into making a new fsm behaviour as the  current one make too many
assumptions of the world beening pure Erlang that just do not fit the
most common use case.

Regards Ingela Erlang/OTP team - Ericsson AB




> On Mon, 30 Nov 2015 at 08:41, Frans Schneider <schneider@REDACTED> wrote:
>
>> For me, implementing the protocol as a gen_fsm feels very natural. Since
>> the unpacking of my data involves splitting the raw data stream in
>> proper chunks, conditionally decrypting these chunks with a stream
>> cypher and lastly decoding them into stanzas according to some mutilated
>> protocol scheme, I think I will use a stack of processes, each specific
>> for the task at hand. Having modules / processes dealing with one
>> particular task feels rather good.
>>
>> Thanks for all the input, which is a great help to me.
>>
>> /Frans
>>
>> On 11/30/2015 08:12 AM, Max Lapshin wrote:
>> > We have fully refused from using gen_fsm and especially in handling
>> > protocol states in gen_fsm.
>> >
>> > Everywhere we use something like:
>> >
>> > handle_info({tcp, Socket, Input},  #state{protocol_state = S0} = State)
>> ->
>> >    {ok, OutputCommands, S1} = some_protocol:handle(Input, S0),
>> >    ..handle somehow OutputCommands
>> >   inet:setopts(Socket, [{active,once}]),
>> >   {noreply, State#state{protocol_state = S1}}.
>> >
>> >
>> > Such approach allows to record Input to file and write a test for
>> > output commands. Also it allows more easily handle situation when
>> > there is more than 1 command in Input packet.
>> >
>> >
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151130/feebdc65/attachment.htm>