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

[Roger Lipscombe]

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? 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.

Regards,
Roger.