Date: Tue, 2 Dec 1997 01:02:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cmott@srv.net (Charles Mott) Cc: hasty@netcom.com, hackers@freebsd.org Subject: Re: ftp server on ftp.cdrom.com Message-ID: <199712020102.SAA26394@usr07.primenet.com> In-Reply-To: <Pine.BSF.3.96.971201150457.9094A-100000@darkstar.home> from "Charles Mott" at Dec 1, 97 03:31:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712020102.SAA26394>