From owner-freebsd-hackers Sat Mar 7 22:29:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12080 for freebsd-hackers-outgoing; Sat, 7 Mar 1998 22:29:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12051 for ; Sat, 7 Mar 1998 22:29:15 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id XAA07622; Sat, 7 Mar 1998 23:29:08 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id XAA03519; Sat, 7 Mar 1998 23:26:55 -0700 (MST) Date: Sat, 7 Mar 1998 23:26:55 -0700 (MST) From: Marc Slemko To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: kernel wishlist for web server performance In-Reply-To: <199803080554.VAA08633@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 7 Mar 1998, Mike Smith wrote: > this regard (ie. have specific HTTP-transmit-file system calls > everywhere)? Now, if you want to talk about HTTP-transmit-file calls and things being specialized for just one protocol, I was actually joking about that earlier today. HTTP-NG, which is currently under very initial development, will almost certainly allow for multiplexed transfers. ie. multiple documents multiplexed over a single TCP connection. A draft spec for that part is at: http://www.w3.org/Protocols/MUX/WD-mux-971203.html Now, consider how to efficiently implement sending small fragments (in SMUX, a fragment is a contiguous bit of data from one of the multiplexed streams in the TCP connection) on the server. With the obvious ways, all these efficiency gains go out the window. So, to get around that, I was joking that an Apache LKM to implement MUX would probably help. No, I'm not really serious because it is such a lame thing to do and has horrible portability. But... this problem is probably going to come up in the future, and I'm still trying to see about efficient ways of doing it. Sigh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message