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

Rory Byrne rory@REDACTED
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'; erlang-questions@REDACTED
> 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: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Rory Byrne
> Sent: Wednesday, June 24, 2015 2:48 PM
> To: erlang-questions@REDACTED
> 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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
-- 



More information about the erlang-questions mailing list