netdev
[Top] [All Lists]

Re: Fwd: Problem with recv syscall on socket when other side closed conn

To: kuznet@xxxxxxxxxxxxx, dyp@xxxxxxxxxxxx (Denis Perchine)
Subject: Re: Fwd: Problem with recv syscall on socket when other side closed connection
From: Denis Perchine <dyp@xxxxxxxxxxxx>
Date: Tue, 27 Jun 2000 08:19:15 +0700
Cc: davem@xxxxxxxxxx, ak@xxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200006261515.TAA22206@ms2.inr.ac.ru>
References: <200006261515.TAA22206@ms2.inr.ac.ru>
Sender: owner-netdev@xxxxxxxxxxx
> > 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@xxxxxxxxxxxx
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

<Prev in Thread] Current Thread [Next in Thread>