Received: by oss.sgi.com id ; Tue, 27 Jun 2000 09:20:09 -0700 Received: from infoteka.nsk.ru ([212.20.32.40]:36869 "HELO infoteka.nsk.ru") by oss.sgi.com with SMTP id ; Tue, 27 Jun 2000 09:10:04 -0700 Received: (qmail 28121 invoked by uid 7770); 27 Jun 2000 16:10:10 -0000 Received: from ppp86.infoteka.nsk.ru (HELO dyp) (dyp@212.20.33.86) by infoteka.nsk.ru with SMTP; 27 Jun 2000 16:10:10 -0000 From: Denis Perchine To: kuznet@ms2.inr.ac.ru Subject: Re: Fwd: Problem with recv syscall on socket when other side closed connection Date: Tue, 27 Jun 2000 23:07:47 +0700 X-Mailer: KMail [version 1.0.29.1] Content-Type: text/plain Cc: davem@redhat.com, ak@muc.de, netdev@oss.sgi.com References: <200006271221.QAA02901@ms2.inr.ac.ru> In-Reply-To: <200006271221.QAA02901@ms2.inr.ac.ru> MIME-Version: 1.0 Message-Id: <00062723125606.00490@dyp> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > > 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. No.... Don't do it... At least I can write workaround with comment: /* Just to make this buggy Linux happy :-(((( */ > 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) Now I start to understand why BSD people hate Linux... Due to such statements. Maybe even this is the correct one, but it breaks programs that works. And it is different from other OSes which makes the task of writing portable programs very hard. Only because Linux kernel people think they are gods. -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------