[erlang-questions] Using ssl (via ranch) {active, once} behaving like {active, twice}

[Ingela Andin]

Hi!

2014-09-09 9:10 GMT+02:00 Roger Lipscombe <roger@REDACTED>:

> On 8 September 2014 19:57, Loïc Hoguin <essen@REDACTED> wrote:
> > Does it do it with normal SSL too or just with Ranch?
>
> I haven't tested with normal SSL at the moment -- I'm only seeing this
> from a single client, and only on one server (the servers are
> chef-identical, btw), so I've not succeeded in reproducing it yet.
>
> > Depending on how you open the socket (for example using the {socket,
> Socket}
> > option) it may have active set to once already, which means it will send
> the
> > message beforehand. Ranch itself shouldn't, but if you open it manually
> it
> > may happen.
>
> We are using {socket, Socket} with ranch, but we're definitely setting
> {active, false} on the listening socket. Is this correctly inherited
> by the connected socket the first time round?



If Ranch uses a pool of accept sockets it is possible that you
you are seeing an inheritance bug in ssl that is fixed in 17.



> Either way, a bunch of
> single-packet messages arrive and are processed successfully first,
> which suggests that we're getting to set {active, once} on that socket
> before this problem occurs. The loop looks (more-or-less) like this:
>
> loop() ->
>   {OK, Closed, Error} = Transport:messages(),    % Transport == ranch_ssl
>   Transport:setopts(Socket, [{active, once}]),
>   receive
>     {OK, Socket, Data} -> start_request(Data),
>     % etc.
>   end
> end.
>
> start_request(Data) ->
>   % message has a size prefix, and might span more than one packet.
>   case needs_more(Data) of
>     true -> get_more_with_recv(),
>     % if you see what I mean
> end.
>
> So, it appears to be in the transition from {active, once} using
> receive to {active, false} -- which should be automatic -- using recv.
> But it only seems to happen when a single message from the client
> spans more than one packet. And it's only happening from this one
> particular client. I don't have any metrics for how often messages
> span more than one packet, unfortunately.
>
> If I test it locally using ssl:send, then it's correct.
>
> Wireshark shows nothing odd about the packets, as far as I can tell,
> it's just that the first one arrives as a message to the controlling
> process, as does the second one (but shouldn't), and the third one
> appears in recv.
>
> We're using R16 -- is this a bug in ssl that's fixed in 17? Is there
> something wrong with the way I'm using it? Should I implement some
> kind of workaround?
>
> The reason that I'm using this active/passive thing is that certain
> kinds of outbound messages are sent as messages to the process from
> elsewhere in the application, and we don't want to send them while
> it's processing an inbound message (because they'll get ahead of the
> response to the inbound message), and since an inbound message can be
> split across multiple packets, we opted to do it this way.
>
>
I would say that from an OTP view of things, the normal way to handle
socket messages is with active once.
>From a supervisor and code upgrading perspective you do usually not want
black a process in a recv call.

Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140909/86bc67a1/attachment.htm>