[erlang-questions] gen_tcp:controlling_process/2 impact

[Benoit Chesneau]

Jachym, Fred thanks for your answers :) It helps.

To elaborate, my original intention was about maintaining different pools
of sockets connections. Each pools would be layered, handling connection
and handshaking if needed. Sockets will be bounded late to requester. For
example in the SSL case:

Process want to open SSL connection
   ---> ask SSL pool if socket if available
        --> no socket available => ask tcp  pool for an available socket
                                                    --> no socket available
                                                          --> connect -->
give the socket to the ssl pool
 --> SSL pool do handshaking if new connected socket
 --> SSL pool return the  socket to the process and give it the control.

Depending on the protocol, i could have a pool maintaining its own set of
sockets. In that case it means at least 3 control passing  (connection job
is also asynchronous). I realise it's probably too much anyway.

In the case of SSL it's should be possible to ask to the TCP pool to do the
final control passing, I guess. But it's probably better to maintain 1 pool
/ protocol and handle the connection jobs differently to reduce the number
of time the control of a socket should be given to a process.

I will try to create a branch for both cases and measure.

Benoit



On Tue, Aug 18, 2015 at 9:07 PM Jachym Holecek <freza@REDACTED> wrote:

> # Fred Hebert 2015-08-18:
> > On 08/18, Benoit Chesneau wrote:
> > If the socket is used only for writing, then you don't need to
> > change the controlling process, just send the thing directly. Anyone
> > can write to a socket, just one process can read.
> >
> > If you do need to read from it, then the best idea is likely to
> > resolve your chain, find the final destination pid, and hand the
> > control there.  The owner must hand the control, so rather than
> > going:
> >
> > a -- give --> b -- give --> c
> >
> > go
> >
> > a -- ask pid --> b -- finds --> c
> > a -- give --> c
>
> Just to give a more elaborate example of what Ferd is saying, from memory:
>
>         accept          peer            connection
>         proc            server          proc
>         -+---------------+--------------+---------
>          |               |
>          o               |                              accept(L) -> S
>          |               |
>          +--------------->                              add_connection(S)
>          |               |
>          |               +-------------->               spawn(S, ...)
>          |               |              |
>          <------------------------------+               reply(..., self())
>          |               |              |
>          o               |              |
>  controlling_process(S, P)
>          |               |              |
>          +------------------------------>               handover_ack
>          |               |              |
>          |               |              o               ready, active true
>
> In Benoit's case there's more than one intermediary, but the overall
> picture
> remains essentially the same.
>
> > which will have a single control-handing form. You can also swap it
> > around and let 'b' tell 'c' to "ask a for your port" and then do the
> > switch.
> >
> > Also remember to let the socket in {accept, false} mode so that no
> > messages are lost during the whole operation.
>
> One wants {active, false} here indeed. Let me add, just in case we're
> talking
> protocol stack implementation, that it may turn out surprisingly convenient
> to perform initial session setup with {active, false} using passive recv()
> instead (intuitively one might lean towards {active, true} socket run by
> a gen_fsm, which may end up nastily overcomplicated). It may also be very
> convenient to do initial session setup from a different process (and
> different code module) than where fully operational session is handled.
>
> Not sure this makes an awful lot of sense without context, just reminded
> me of something in my previous projects... Nevermind if not. :-)
>
> Have fun,
>         -- Jachym
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150820/e37b041f/attachment.htm>