From:   Denis Perchine <dyp@perchine.com>
To:     kuznet@ms2.inr.ac.ru, dyp@perchine.com (Denis Perchine)
Subject: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date:   Tue, 27 Jun 2000 08:19:15 +0700
Content-Type: text/plain
Cc:     davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
References: <200006261515.TAA22206@ms2.inr.ac.ru>
In-Reply-To: <200006261515.TAA22206@ms2.inr.ac.ru>
MIME-Version: 1.0
Message-Id: <0006270823180R.00485@dyp>
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Content-Length: 1300
Lines: 34

> > There's quite strange behavior of the linux kernel when other side closed connection
> > and we try to read from socket.
> > Firstly I get -1 and EPIPE in errno. Hmmm... I could not find anywhere in standards or manpages
> > that recv can return EPIPE. OK...
> 
> Apparently, your last write() failed and you get asynchronous error
> notification. What does freebsd return? ECONNRESET?

Sorry... But seems that you did not understand the problem.
I talk about recv... Not write... write SHOULD give EPIPE on connection reset...
But not recv/read.
 
> Solaris returns EPIPE as well. And EPIPE really looks as sematically
> correct code. read() is OK, previous write() failed.
> 
> > The if I try to continue read I will get the rest of the data which arrived between last read and
> > connection close...
> 
> Of course. Do you propose to lose this data? 8)

Usual way of handling connection reset when you do only read is to give
all data available and then return 0, indicating EOF.
Or some OSes (HPUX if I'm not mistaken) gives you all data available and then
ECONNRESET. But not other way around...

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------