From owner-cvs-all Thu Jun 15 12:14:42 2000 Delivered-To: cvs-all@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D56DB37B5D7; Thu, 15 Jun 2000 12:14:26 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA29528; Thu, 15 Jun 2000 13:14:25 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA25610; Thu, 15 Jun 2000 13:14:24 -0600 (MDT) (envelope-from nate) Date: Thu, 15 Jun 2000 13:14:24 -0600 (MDT) Message-Id: <200006151914.NAA25610@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: Nate Williams , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys/sys socket.h In-Reply-To: <20000615120807.M18462@fw.wintelcom.net> References: <200006151818.LAA31278@freefall.freebsd.org> <200006151845.MAA25472@nomad.yogotech.com> <20000615120807.M18462@fw.wintelcom.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > alfred 2000/06/15 11:18:43 PDT > > > > > > Modified files: > > > sys/kern uipc_socket.c uipc_socket2.c > > > sys/sys socket.h > > > Log: > > > add socketoptions DELAYACCEPT and HTTPACCEPT which will not allow an accept() > > > until the incoming connection has either data waiting or what looks like a > > > HTTP request header already in the socketbuffer. > > > Reviewed by: silence on hackers. > > > > Huh? I never saw this. I object to adding application specific code > > inside the kernel. > > It's not really a signifigant amount of code if you look at the > delta, the performance difference is signifigant though. > You'll be happy when I release my http server that uses this. > > The final patch is up at: > > http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > Here is the original message titled: "big patch" > > >From bright@wintelcom.net Tue Jun 13 17:04:32 2000 > Date: Tue, 13 Jun 2000 17:23:37 -0700 > From: Alfred Perlstein > To: hackers@freebsd.org > Subject: big patch: rlimits, accept filters and kblob. This subject line (which I do remember) has no mention of HTTP application code. > Message-ID: <20000613172336.S18462@fw.wintelcom.net> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.2i > Status: RO > Content-Length: 1856 > Lines: 52 > > Hey guys, I have some patches here which implement a number of things. > > 1) fixes dangerous races in per-uid limiting code This is a bug-fix. > 2) 2 accept filters which will not mark a socket as completed for accept() > until either: > 1) there is data available to be read > 2) there is an http request in the socketbuffer I didn't think there was a consensus on this, or on kblob. Neither was there much discussion on this. Also, I *really* don't like the accept() changes, since we (and a number of others) are currently taking advantage of the fact that we can 'ping' a host by contacting a known port and if accepts the connection, which we subsuquently close. ICMP is often filtered, but in our equipment (which happens to be installed the customer's site), we run a the 'echo' port for our internal ping. Waiting until data is sent (or received) is a bad thing, IMO, and probably violates the TCP specifications. > 3) kblob, a kernel hack for preloading data into the kernel to send out > on multiple descriptors, very similar to sendfile but more lightweight > and pretty useful for serving many small chunks of data over stream > sockets. I'd like *alot* more discussion on this. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message