What OTP behaviors should I use for this?

Question

I've got a server that accepts TCP connections (a gen_server using gen_tcp) and for each connection it spawns a supervisor. That supervisor (supervised by another, more permanent supervisor) then spawns two processes: a protocol-specific handler and a client context that talks to the database.

The protocol handler takes TCP messages from the socket and turns them into messages for the client context. The client context takes those messages and talks to the database and returns messages that the protocol handler turns into whatever protocol it's using over TCP (telnet, ssh, websockets, HTTP...) and sends them back to the client.

What I want to know is what OTP behaviors are appropriate for the protocol handler and client context processes. I could abuse gen_server, but it's 1 connection per process pair. The gen_fsm looks like it could work for the protocol handler, since there are a couple states it goes through, but it's pretty inappropriate for the client context. I was thinking about gen_event for the client context, but I've been led to believe that's intended more for event aggregators, and this only handles events from a single source.

Feel free to tell me I'm going about this completely the wrong way, it's the first time I've tried to make an OTP application anywhere near this complex.

Answer 1

It sounds like you are trying to reimplement the acceptor pool found in Cowboy. This application masquerades itself as a small HTTP server but it is really just a socket server in its core, see how Andrew Thompson used it for its own gen_smtp.

Answer 2

I think using a supervisor to 'group' the two processes is not needed. So, a single supervisor for the TCP protocol handlers (assuming they are singleton), and a simple_one_for_one for the client context gen_server. When a new connection is received, the simple_one_for_one supervisor is asked to create a new client context gen_server. Make sure the two processes know each others Pid so they can communicate, and perhaps link them up for error handling.