[erlang-questions] Abandoned (ranch) connection processes?

Dmitry Kolesnikov dmkolesnikov@REDACTED
Thu Feb 15 12:58:11 CET 2018


Hello,

As far, I’ve understood from you explantation... We have a following “sequence” of operations when accepting socket and upgrading a connection to ssl:

A. ssl:transport_accept(...)
B. ssl:ssl_accept(...)
C. ssl:setopts(…, [{active, once}])

Before (C) socket in passive mode. No one guarantees that {ssl_closed, …} is delivered to you. Therefore, you need to check error codes of each socket operation and react in correspond manner. E.g. if connection is dropped between B and C then return you an error.  

— CLIP — 
When an SSL socket is in active mode (the default), data from the socket is delivered to the owner of the socket in the form of messages:

{ssl, Socket, Data}

{ssl_closed, Socket}

{ssl_error, Socket, Reason}

— CLIP — 
 
Best Regards, 
Dmitry


> On 15 Feb 2018, at 13.23, Roger Lipscombe <roger@REDACTED> wrote:
> 
> OK. Let me rephrase that:
> 
> - {active, once} obviously has something in place to handle data
> arriving and closed sockets *in between* calls to {active, once} --
> i.e. it'll be {active, false} for a brief interval. I last looked at
> this code in 17.x (before the gen_statem refactoring), so I'm not sure
> where it lives now.
> - does it deal correctly with closed sockets that close before the
> *first* call to {active, once}? In other words: can I expect an
> ssl_closed message in this case? Is there something special about the
> first call?
> 
> On 15 February 2018 at 11:15, Dmitry Kolesnikov <dmkolesnikov@REDACTED> wrote:
>> Hello,
>> 
>> On 15 Feb 2018, at 13.08, Roger Lipscombe <roger@REDACTED> wrote:
>> 
>> The only thing I can think of is that the socket is being closed
>> between ranch:accept_ack and Transport:setopts, and Erlang's not
>> sending the ssl_closed message. Does this sound likely? How do I deal
>> with this?
>> 
>> 
>> No, it does not sound likely! The bug is either at ranch or your code.
>> 
>> I think you should try to verify the result of each socket operation before
>> going further on. I am referring here to your statement: I'm *not* verifying
>> the result.
>> 
>> 
>> Best Regards,
>> Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180215/f44b3bb2/attachment.htm>


More information about the erlang-questions mailing list