[erlang-questions] gen_fsm and active sockets

[igwan]

Hello,

Dave Smith wrote :
> Greetings,
>
> I'm using gen_fsm to manage a socket connection, and have a question
> about how one SHOULD use gen_fsm for this purpose. I'm specifically
> using the "active" mode for the socket [...]
>   
Using the 'active' mode means you have no way to control the flow of 
data coming from the network. They will accumulate as messages in your 
processes' mailboxes if you can't keep up, and severely alter 
responsivity of the system. So be sure you can handle the full load, 
especially if you want to do much computation on incoming data. However, 
in practice it is likely you'll be more limited by the cpu time consumed 
by the VM just to receive packets than by the actual computation 
performed by your processes. (was the case in R11B-5, see 
http://www.nabble.com/gen_tcp-receving-slow-tt12870823.html , haven't 
checked with R12B yet).
> 1. Receive socket events on a dedicated process and pass events into
> gen_fsm via that process. Upside is that this provides nice separation
> of socket and fsm logic. Downside there is that I'm doubling the
> number of processes -- i.e. i had one process per socket, now I have
> two. That's not a big problem with a couple of thousand connections,
> but once I'm in the 20k-30k connections realm, I'm not quite sure what
> the implications of doubling the number of processes is. Is it
> "normal" in a production system to run 100k+ processes? Note: I'm
> still recovering from pthreads land, where 100k+ theads is a scary,
> scary thing -- so maybe this concern over # of processes is a
> threading world "hangover" :)
>   
It would not only double the number of process (that's a memory impact), 
but also the number of messages (a cpu time impact).
> 2. Receive socket events in handle_info and invoke
> gen_fsm:send_event() from there. This seems like the "obvious"
> approach, but it feels wrong -- I'm already in process and don't
> really want to queue up another event. Again, possibly a "hangover"
> from non-Erlang land.
>   
Doubling the number of message too.
> 3. Receive socket events in handle_info, then do a
> ?MODULE:StateName({socket_event ...}, State). Avoids (perceived)
> overhead of approach #3, but...is this a good idea?!
>   
This is how I would do (and have done for a HTTP server). It has very 
little overhead (just a function call) and keeps the code readable. But 
i'll let the gurus give you a definitive advice :)
You might want to check-out this tutorial on "non blocking TCP server 
using OTP principles" 
http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles 
.
The author uses option #3.

regards,

--
igwan