[erlang-questions] {error,closed} vs. {error,econnreset}

Rory Byrne <>
Mon Sep 26 16:15:21 CEST 2016


Hi Andras,

I'm answering this because you addressed my directly.

At the current moment I am not in a position to speak with any authority
regarding the code in inet_drv.c. It's been over a year since I last looked
at this code and it would take me a good few hours to get to a point where
I was comfortable to comment on it again.

If you sniff the wire and can confirm with absolute certainty that the
peer is sending an RST that is getting reported as {error, closed} in
Erlang, then I'll make the time to look into it. Needless to say, you
would need to provide significantly more information about the scenario
in which this occurred: OS where Erlang is running, OS on the peer, all
the socket options you set, the exact call(s) where you received
{error, closed}, etc. Ideally you'd be able to provide a tcpdump trace of
when the connection went down; it wouldn't need to be a deep trace, just
enough to see the details of the TCP traffic (flags, sequence numbers,
etc).

Regards,

Rory


On Thu, Sep 22, 2016 at 12:51:38PM +0000, Bekes, Andras G wrote:
> Hi Rory, All,
> 
> Let me revive this old thread for a minute. The new gen_tcp option {show_econnreset, true} works well.
> 
> However, we still notice some cases when we observe {error,closed} on the Erlang side, but other signs suggest that the TCP connection wasn't intentionally closed by the peer, but was closed because of some error.
> We suspect some packets being dropped by the OS due to various buffer overruns.
> I am not very familiar with packet-level details of TCP. Can someone confirm if there are other erroneous terminations of a TCP connection (other than econnreset), reported simply as {error,closed} by Erlang?
> 
> I tried checking the code erts/emulator/drivers/common/inet_drv.c and it seems to me not, but can someone actually understanding that code also confirm? 
> 
> Thank you very much,
>    Andras
> 
> -----Original Message-----
> From: Bekes, Andras G (ICT) 
> Sent: Tuesday, August 11, 2015 2:43 PM
> To: 'Rory Byrne'; 
> Subject: RE: [erlang-questions] {error,closed} vs. {error,econnreset}
> 
> Hi Rory,
> 
> I just tested this new feature in Erlang/OTP R18 and it works fine.
> 
> Thank you very much all for implementing it!
> 
> Regards,
>    Andras
> 
> -----Original Message-----
> From:  [mailto:] On Behalf Of Rory Byrne
> Sent: Wednesday, June 24, 2015 2:48 PM
> To: 
> Subject: Re: [erlang-questions] {error,closed} vs. {error,econnreset}
> 
> Hi Andras,
> 
> On Tue, May 05, 2015 at 07:44:47AM +0000, Bekes, Andras G wrote:
> > Thank you very much for your efforts Rory.
> > 
> > The ability "to set a socket option that shows all econnreset errors" sounds like the right solution. I am wondering why hiding this detail is the default, but I believe there were good enough reasons to design it that way.
> > 
> > I accept that your solution will not notice the connection reset event in some corner cases. I think this will not apply in my case: I am sending a small amount of data (<1KB) and wait for the reply.
> > 
> > I am looking forward to see your patch in the next release of Erlang/OTP!
> 
> The fix for this is in the 18.0 release. It should take care of the corner cases too.
> 
> Use the socket option '{show_econnreset, true}' and you'll receive {error, econnreset} in passive mode or {tcp_error, Socket, econnreset} in active mode. See the docs [1] for more information.
> 
> Regards,
> 
> Rory
> 
> [1] http://www.erlang.org/doc/man/inet.html#setopts-2
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> --------------------------------------------------------------------------------
> 
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers  If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.

-- 


More information about the erlang-questions mailing list