<div dir="ltr">Hi!<div><br></div><div><div class="gmail_extra"><div class="gmail_quote">2015-11-30 8:42 GMT+01:00 Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">isn't the ssl module using a gen_fsm?<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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</div><div>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</div><div>most common use case.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_quote"><div dir="ltr">On Mon, 30 Nov 2015 at 08:41, Frans Schneider <<a href="mailto:schneider@xs4all.nl" target="_blank">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>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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>
<br></blockquote></div><br></div></div></div>