isn't the ssl module using a gen_fsm?<br><div class="gmail_quote"><div dir="ltr">On Mon, 30 Nov 2015 at 08:41, Frans Schneider <<a href="mailto:schneider@xs4all.nl">schneider@xs4all.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For me, implementing the protocol as a gen_fsm feels very natural. Since<br>
the unpacking of my data involves splitting the raw data stream in<br>
proper chunks, conditionally decrypting these chunks with a stream<br>
cypher and lastly decoding them into stanzas according to some mutilated<br>
protocol scheme, I think I will use a stack of processes, each specific<br>
for the task at hand. Having modules / processes dealing with one<br>
particular task feels rather good.<br>
<br>
Thanks for all the input, which is a great help to me.<br>
<br>
/Frans<br>
<br>
On 11/30/2015 08:12 AM, Max Lapshin wrote:<br>
> We have fully refused from using gen_fsm and especially in handling<br>
> protocol states in gen_fsm.<br>
><br>
> Everywhere we use something like:<br>
><br>
> handle_info({tcp, Socket, Input},  #state{protocol_state = S0} = State) -><br>
>    {ok, OutputCommands, S1} = some_protocol:handle(Input, S0),<br>
>    ..handle somehow OutputCommands<br>
>   inet:setopts(Socket, [{active,once}]),<br>
>   {noreply, State#state{protocol_state = S1}}.<br>
><br>
><br>
> Such approach allows to record Input to file and write a test for<br>
> output commands. Also it allows more easily handle situation when<br>
> there is more than 1 command in Input packet.<br>
><br>
><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>