From:   kuznet@ms2.inr.ac.ru
Message-Id: <200006271221.QAA02901@ms2.inr.ac.ru>
Subject: Re: Fwd: Problem with recv syscall on socket when other side closed connection
To:     dyp@perchine.com (Denis Perchine)
Date:   Tue, 27 Jun 2000 16:21:55 +0400 (MSK DST)
Cc:     dyp@perchine.com, davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
In-Reply-To: <0006270823180R.00485@dyp> from "Denis Perchine" at Jun 27, 0 08:19:15 am
MIME-Version: 1.0
Content-Length: 1513      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk

Hello!

> 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.

I did understand. This error was for write(), but it became known
_after_ you exited write(). So that it is delivered to read().
It is usual problem of all full-duplex pipes.

We could translate this EPIPE to ECONNRESET, when it is delivered
to read(), but it does not change its sense.

Solaris does not translate.


> Usual way of handling connection reset when you do only read is to give
> all data available and then return 0, indicating EOF.

Sorry? Think a bit.

You wrote to dead socket, right? It is the hardest error.
If the transport were local, you would get SIGPIPE and died painful death.
If an OS ignores such events, it is simply impossible to use,
you will get silently truncated data all the time.


> Or some OSes (HPUX if I'm not mistaken) gives you all data available and then
> ECONNRESET. But not other way around...

This approach has its merits, and it is acceptable in principle.

But Linux approach is evidently better, because errors are expedited.
Each protocol, where out of band events are inlined to data
is inclined to deadlocks.

In Linux scheme you know forward that stream is aborted.
Depending on protocol you may choose to abort protocol
or to continue to operate, parsing already received messages.


> 		But not other way around...

You have just seen a new way around. The correct one. 8)

Alexey