Received: by oss.sgi.com id ; Mon, 26 Jun 2000 18:49:41 -0700 Received: from infoteka.nsk.ru ([212.20.32.40]:63242 "HELO infoteka.nsk.ru") by oss.sgi.com with SMTP id ; Mon, 26 Jun 2000 18:49:31 -0700 Received: (qmail 29306 invoked by uid 7770); 27 Jun 2000 01:49:27 -0000 Received: from ppp86.infoteka.nsk.ru (HELO dyp) (dyp@212.20.33.86) by infoteka.nsk.ru with SMTP; 27 Jun 2000 01:49:27 -0000 From: Denis Perchine To: "David S. Miller" Subject: Re: Fwd: Problem with recv syscall on socket when other side closed connection Date: Tue, 27 Jun 2000 08:45:46 +0700 X-Mailer: KMail [version 1.0.29.1] Content-Type: text/plain Cc: kuznet@ms2.inr.ac.ru, ak@muc.de, netdev@oss.sgi.com References: <200006261515.TAA22206@ms2.inr.ac.ru> <0006270823180R.00485@dyp> <200006270131.SAA03319@pizda.ninka.net> In-Reply-To: <200006270131.SAA03319@pizda.ninka.net> MIME-Version: 1.0 Message-Id: <0006270852390S.00485@dyp> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 1792 Lines: 38 > 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... > > Connection reset effectively means that TCP's reliable data transport > has been completely compromised, and therefore any attempt to move > data across that socket should immediately indicate an error. > > What I am also trying to say is that when one says "all the data > available", the rest of the connection has in effect dropped all > meaning to that phrase, you no longer know what "all the data" is > and between two different reset occurances "all the data" will be > different so why would you want to read any of it at all? I need to read all data BEFORE reset occurs. The problem is that I get EPIPE before I get the data recieved before the reset. Just live example. I have a connection to PostgreSQL database. And for some reason that connection was reset by database server. This can happend due to enumerous number of errors. Before close the connection server wrote the reason to it. The problem is that in the case of Linux I will not get this data unless I will provide some special handling for this (just ignore SIGPIPE from recv). This is not the case on other OSes. I also can not understand whether such behavoir compatible with POSIX specs or not? As far as I can remember recv can not return EPIPE in any case. At least there's no any mention about this in man pages, info, and other docs I have. -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------