[erlang-questions] the supervisor_bridge behaviour

[Essien Essien]

Hi,

On Thu, May 7, 2009 at 11:37 AM, Gamoto <gamoto@REDACTED> wrote:
> I don't have an existing application. I am building it and I don't know which kind of behaviour I must put.
> That would say, I have no reason to use supervisor_bridge ?

Actually, there is no "supported" OTP behaviour to allows easy writing
of stuff like TCP servers, in the way that feels more or less
"natural"

>
> I want to supervise several "client-server" processes, each one specialized for one protocol.
> I use gen_tcp primitives (listen,accept,recv,send,close) , not gen_server.
>
> I try to explain my structure: you can correct it of course !
> main_supervisor supervises the client-server processes (called SRV later), one for one strategy, behaviour = supervisor
> If one SRV hangs, the other one shall not be disturbed.
> One SRV can receive several connection from several clients. If one socket hangs, the other one shall not be disturbed.
> I suppose that the SRV is also a supervisor of processes.
> SRV manages the listen primitive. For each accept, a process (called P later) is created to manage the recv/send primitives.
>
> And now I am lost. Behaviour of SRV ? addition or not of an supervisor between SRV and the  P processes ? if yes, behaviour ? why ?

I think what you're encountering is what most Network programmers new
to Erlang ask: How do you create Networked Servers using the OTP
principles/behaviours? The key to this is actually that the OTP
principles basically encourage Asynchronity vs Synchronity, which the
gen_tcp class of functionality are synchronous in operation.

That said, there is a recipe on trapexit that shows how to build an
Asynchronous TCP Server using OTP gen_server behaviour, which I think
you may at least want to take a peek at:

http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles

I've used this quite extensively, and tried to codify a reusable
behaviour to make it easier to use.

The behaviour code is at:
http://github.com/essiene/jsonevents/blob/5b892e0fb0e95aeb9883a53415f2be1dabad6a0d/src/gen_listener_tcp.erl

Two use cases of this behaviour are at:
http://github.com/essiene/jsonevents/blob/5b892e0fb0e95aeb9883a53415f2be1dabad6a0d/src/jsonevents_server_ssl.erl

http://github.com/essiene/jsonevents/blob/5b892e0fb0e95aeb9883a53415f2be1dabad6a0d/src/jsonevents_server_tcp.erl

Use at your own peril ;)

Hope this helps in someway.

cheers,
Essien
>
> John
>
> The documentation on internet is very limited on this subject ...
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>