From owner-freebsd-hackers Tue Dec 2 01:44:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15962 for hackers-outgoing; Tue, 2 Dec 1997 01:44:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15956 for ; Tue, 2 Dec 1997 01:44:16 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id BAA16682; Tue, 2 Dec 1997 01:46:34 -0800 (PST) Message-Id: <199712020946.BAA16682@implode.root.com> To: Charles Mott cc: hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com In-reply-to: Your message of "Tue, 02 Dec 1997 02:05:39 MST." From: David Greenman Reply-To: dg@root.com Date: Tue, 02 Dec 1997 01:46:34 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Anyway, I don't mean to squelch the conversation regarding this, but >> I do ask that people not make silly assumptions without first actually >> studying the problem. >> >> -DG > >No aspersions were intended towards your ftpd, at least on my earlier None taken. >Shared memory and advisory locking are a big nuisance to deal with when >trying to make software cleanly compile across different platforms and >kernel configurations. Threading eliminates the need for these things but >also creates other headaches. For moderate numbers of open sockets (50 to >100), a synchronous state machine with non-blocking I/O doesn't sound that >bad for some of my modest needs (far smaller than the Mt. Everest of >wcarchive). One of the reasons why I'm not releasing my hacked-up ftpd server is that it doesn't have any of the portability stuff of wu-ftpd (and never will). It is further highly FreeBSD-centric, even to the point of being built with it's own hacked up libc. Trying to support this in any general sense would be a nightmare...supporting FreeBSD is plenty enough to keep me awake at night. :-) >>From your standpoint, would there be performance advantages to 50 >processes each handling 50 connections vs. 2500 processes? Or as you say, >are sockets and disk I/O the primary thing? I think when the numbers of connections are on the order of 50-100, it doesn't make much difference which method you use. The traditional method of fork/exec for each ftpd is, however, rather expensive, so any server expected to do moderate to heavy work should at least run standalone - not from inetd. Other than that, I don't think a monolithic server (multi- threaded or a big state machine) vs. a one server process per connection is going to matter. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project