<div dir="ltr">Hi!<br><div class="gmail_extra"><br><div class="gmail_quote">2014-09-09 9:10 GMT+02:00 Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8 September 2014 19:57, Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br>
> Does it do it with normal SSL too or just with Ranch?<br>
<br>
</span>I haven't tested with normal SSL at the moment -- I'm only seeing this<br>
from a single client, and only on one server (the servers are<br>
chef-identical, btw), so I've not succeeded in reproducing it yet.<br>
<span class=""><br>
> Depending on how you open the socket (for example using the {socket, Socket}<br>
> option) it may have active set to once already, which means it will send the<br>
> message beforehand. Ranch itself shouldn't, but if you open it manually it<br>
> may happen.<br>
<br>
</span>We are using {socket, Socket} with ranch, but we're definitely setting<br>
{active, false} on the listening socket. Is this correctly inherited<br>
by the connected socket the first time round? </blockquote><div><br></div><div><br></div><div>If Ranch uses a pool of accept sockets it is possible that you</div><div>you are seeing an inheritance bug in ssl that is fixed in 17.  </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Either way, a bunch of<br>
single-packet messages arrive and are processed successfully first,<br>
which suggests that we're getting to set {active, once} on that socket<br>
before this problem occurs. The loop looks (more-or-less) like this:<br>
<br>
loop() -><br>
  {OK, Closed, Error} = Transport:messages(),    % Transport == ranch_ssl<br>
  Transport:setopts(Socket, [{active, once}]),<br>
  receive<br>
    {OK, Socket, Data} -> start_request(Data),<br>
    % etc.<br>
  end<br>
end.<br>
<br>
start_request(Data) -><br>
  % message has a size prefix, and might span more than one packet.<br>
  case needs_more(Data) of<br>
    true -> get_more_with_recv(),<br>
    % if you see what I mean<br>
end.<br>
<br>
So, it appears to be in the transition from {active, once} using<br>
receive to {active, false} -- which should be automatic -- using recv.<br>
But it only seems to happen when a single message from the client<br>
spans more than one packet. And it's only happening from this one<br>
particular client. I don't have any metrics for how often messages<br>
span more than one packet, unfortunately.<br>
<br>
If I test it locally using ssl:send, then it's correct.<br>
<br>
Wireshark shows nothing odd about the packets, as far as I can tell,<br>
it's just that the first one arrives as a message to the controlling<br>
process, as does the second one (but shouldn't), and the third one<br>
appears in recv.<br>
<br>
We're using R16 -- is this a bug in ssl that's fixed in 17? Is there<br>
something wrong with the way I'm using it? Should I implement some<br>
kind of workaround?<br>
<br>
The reason that I'm using this active/passive thing is that certain<br>
kinds of outbound messages are sent as messages to the process from<br>
elsewhere in the application, and we don't want to send them while<br>
it's processing an inbound message (because they'll get ahead of the<br>
response to the inbound message), and since an inbound message can be<br>
split across multiple packets, we opted to do it this way.<br>
<br></blockquote><div><br></div><div>I would say that from an OTP view of things, the normal way to handle socket messages is with active once. </div><div>From a supervisor and code upgrading perspective you do usually not want black a process in a recv call.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div><div> </div></div></div></div>