[erlang-questions] gen_tcp under gen_server design

[Logan, Martin]

Andrew, BTW - you should not have to use controlling process. Have the listen sock spawned in your application behaviour implementation module, then pass it through to each acceptor which blocks on accept in the handle_info(timeout clause which is prompted by using a timeout of 0 out of init/1. Once you accept call into the simple_one_for_one supervisor that is  responsible for spawning off your acceptors and have it spawn another one to wait for the next connection while the first chugs along processing on a socket it already owns by virtue of the fact that it accepted it. There is no worry here between accepting one connection and spawning another to accept the next because the OS queues up pending connections of which the call to accept/1 only pulls off the first one.

Hope that helps.

Cheers,
Martin


On 7/30/10 9:58 AM, "Andre Nathan" <andre@REDACTED> wrote:

Hello

I'm building my first OTP application. It's a network server that deals
with a binary protocol. My question is about the design I came up to fit
a gen_tcp server into the gen_server behaviour.

The idea is to have a server process (a gen_server) which listens on a
given port and spawns an acceptor process. This process is created with
proc_lib:spawn_link and the listening socket is passed to it with
gen_tcp:controlling_process; it doesn't implement any OTP behavior.

The acceptor process calls gen_tcp:accept, and when the call returns, a
new process responsible for handling the data is spawned. The client
socket is given to this process via gen_tcp:controlling_process, and the
acceptor calls gen_tcp:accept again waiting for new connections.

I call the process created by the acceptor the "packager" process. It's
a simple gen_fsm that reads binary data from the socket and packages it
into binaries of the appropriate size, according to the protocol, parses
them and generate the appropriate events on the worker process that
implements the protocol FSM. The packager process receives tcp data in
the handle_info callback, which sets the socket to {active, once} each
time it is called and calls the function corresponding to the current
gen_fsm state, generating a "data" event.

Is this a reasonable design for this kind of server? Is there anything I
could do to improve its reliability and/or efficiency? Would it be
better to, for example, have multiple acceptor processes and let them do
the binary processing that the packager processes do in my case by
themselves?

Thanks in advance,
Andre


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED