From owner-cvs-all Sun Sep 17 12:44:11 2000 Delivered-To: cvs-all@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C330737B422; Sun, 17 Sep 2000 12:44:07 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA58478; Sun, 17 Sep 2000 15:44:07 -0400 (EDT) (envelope-from wollman) Date: Sun, 17 Sep 2000 15:44:07 -0400 (EDT) From: Garrett Wollman Message-Id: <200009171944.PAA58478@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_accf.c src/sys/netinet accf_http.c src/sys/sys socketvar.h In-Reply-To: <20000907022131.V18862@fw.wintelcom.net> References: <200009061849.LAA34906@freefall.freebsd.org> <20000907023342.G656@hand.dotat.at> <20000907022131.V18862@fw.wintelcom.net> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Clearing out some old mail...] < said: > That's possible, but right now I'd like to fix the way listen() > overflows are handled. (make them FIFO) Listen queue overflows are handled the way they are in order to mitigate certain classes of DoS attacks. As it happens, I think the code is not written as efficiently as it could have been[1], but drop-tail is definitely the wrong queueing model for the listen queue. -GAWollman [1] Specifically, the code attempts to implement random drop, but does so in rather inefficiently. Rather than indexing the listen queue to find a random connection to drop, a more efficient implementation would implement the strategy described in the RED paper; that being to choose a random interval (with mean proportional to the average fullness of the queue) and then simply drop the new connection at that interval. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message