From owner-freebsd-hackers Mon Dec 1 17:03:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09995 for hackers-outgoing; Mon, 1 Dec 1997 17:03:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09979 for ; Mon, 1 Dec 1997 17:03:06 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA07333; Mon, 1 Dec 1997 11:26:38 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd007307; Mon Dec 1 11:26:31 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id SAA26394; Mon, 1 Dec 1997 18:02:16 -0700 (MST) From: Terry Lambert Message-Id: <199712020102.SAA26394@usr07.primenet.com> Subject: Re: ftp server on ftp.cdrom.com To: cmott@srv.net (Charles Mott) Date: Tue, 2 Dec 1997 01:02:15 +0000 (GMT) Cc: hasty@netcom.com, hackers@freebsd.org In-Reply-To: from "Charles Mott" at Dec 1, 97 03:31:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Initially, I was thinking that port 20 data transfers (as opposed to port > 21 control traffic) had to be either separate processes or threads, but > now I think you are right -- everything could be done by a synchronous > state machine in a single user process, but this might be inefficient. Unless you used aioread/aiowrite/aiowait/aiocancel from John Dyson's /sys/kern/vfs_aio.c in -current. Then you could overlap I/O. The distinction to be made here is that async I/O and call-conversion threading mechanisms do not scale on SMP (ie: adding more processors does not make the work get done any more swiftly). The main drawback to user space threading mechanisms (like pthreads and user context management with aio and/or "sigsched", etc.) is SMP and/or cluser scalability. This should, however, work as well as "ddd" or "team". > As a compromise to the asynchronous nature of communications, one could > imagine a four process implementation; > > (1) port 21 state machine that wakes up whenever there is > control input. > > (2) state machine which handles all port 21 response messages. > > (3) data process that handles all incoming data. > > (4) data process that handles all outgoing data. > > Although a state machine scales quite well, there are OS problems related > to the number of open socket descriptors per process. Also, I am not sure > how select() will work in multiplexing a large number of sockets. When > packets start queueing up in the kernel, will they be given to a process > in order of receipt? Part of the brains behind a "work to do engine" design is that you use sfork to share a single per process open file table between several processes ("kernel threads") to overcome this problem. You can also pass off fd's between processes if you don't want to use sfork. ---------------------------------------------------------------------------- #36 of Things Computer Scientists Do That Make No Sense To The Clueless(tm) ---------------------------------------------------------------------------- As an interesting experiment, build "team" for your WWW server, and replace your GIF's with cgi's that use "team" to blow the GIF's out using multiple process overlapped I/O. Wheee! Now your WWW server seems much faster, doesn't it? (Note: team's synchronization on an SMP SPARC box fails -- Solaris has a bug -- use "ddd" instead if you run the experiment there). ---------------------------------------------------------------------------- You could do FTP the same way... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.