Date: Fri, 28 May 2010 12:26:33 +0300 From: Mikolaj Golub <to.my.trociny@gmail.com> To: "Lavrentiev\, Anton \(NIH\/NLM\/NCBI\) \[C\]" <lavr@ncbi.nlm.nih.gov> Cc: freebsd-net@FreeBSD.org, "Robert N. M. Watson" <rwatson@FreeBSD.org>, bug-followup@FreeBSD.org Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by peer) wrongly Message-ID: <86mxvkqsvq.fsf@zhuzha.ua1> In-Reply-To: <201005280440.o4S4e3sM052201@freefall.freebsd.org> (Anton Lavrentiev's message of "Fri, 28 May 2010 04:40:03 GMT") References: <201005280440.o4S4e3sM052201@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 May 2010 04:40:03 GMT Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: LA> IMHO, it is not, unfortunately, a solution: it seems to clear ECONNRESET LA> blindly and w/o distinguishing the situation when the remote end closes the LA> connection prematurely (i.e. before acknowledging all data written from the LA> local end) -- and that qualifies for the true "connection reset by peer" LA> from close()... I am not very familiar with the socket/tcp code but it looks for me that it might not make any difference. I can be wrong here but the situation you have described as true "connection reset by peer" seems to have the following path in the code: soclose() -> sodisconnect() -> tcp_usr_disconnect() -> tcp_disconnect() But tcp_disconnect() does not return error, so we will not have ECONNRESET error in any case. May be you have a good test suite to reproduce this situation? :-) -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86mxvkqsvq.fsf>