Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 29 Apr 2002 04:06:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 29 Apr 2002 04:06:46 -0400 Received: from elin.scali.no ([62.70.89.10]:59660 "EHLO elin.scali.no") by vger.kernel.org with ESMTP id ; Mon, 29 Apr 2002 04:06:46 -0400 Subject: Re: Possible bug with UDP and SO_REUSEADDR. From: Terje Eggestad To: David Schwartz Cc: linux-kernel In-Reply-To: <20020429004153.AAA18838@shell.webmaster.com@whenever> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 29 Apr 2002 10:06:43 +0200 Message-Id: <1020067604.22026.3.camel@pc-16.office.scali.no> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2002-04-29 at 02:41, David Schwartz wrote: > > > On Thu, 25 Apr 2002 19:43:01 -0700 (PDT), David S. Miller wrote: > >From: Terje Eggestad > >Date: 25 Apr 2002 14:37:44 +0200 > > > >However writing a test server that stand in blocking wait on a UDP > >socket, and start two instances of the server it's ALWAYS the server > >last started that get the udp message, even if it's not in blocking > >wait, and the first started server is. > > > >Smells like a bug to me, this behavior don't make much sence. > > > >Using stock 2.4.17. > > > >Can you post your test server/client application so that I > >don't have to write it myself and guess how you did things? > > There are really two possibilities: > > 1) The two instances are cooperating closely together and should be sharing > a socket (not each opening one), or > > 2) The two instances are not cooperating closely together and each own their > own socket. For all the kernel knows, they don't even know about each other. > > In the first case, it's logical for whichever one happens to try to read > first to get the/a datagram. In the second case, it's logical for the kernel > to pick one and give it all the data. > > DS > IMHO, in the second case it's logical for the kernel NOT to allow the second to bind to the port at all. Which it actually does, it's the normal case. When you set the SO_REUSEADDR flag on the socket you're telling the kernel that we're in case 1). TJ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/