Date: Mon, 1 Dec 1997 15:31:16 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Amancio Hasty Jr <hasty@netcom.com> Cc: hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com Message-ID: <Pine.BSF.3.96.971201150457.9094A-100000@darkstar.home> In-Reply-To: <199712012138.NAA03509@netcom14.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Dec 1997, Amancio Hasty Jr wrote:
>
> Actually, I was thinking more along the lines of state machine with
> the functionality to share data transfers you know to avoid the
> case of hundreds of users opening a single file N times.
>
> Most network engineers are familiar with an event or a state machine
> driven network server .
>
> Cheers,
> Amancio
>
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.
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?
Charles Mott
(who really likes state machines)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971201150457.9094A-100000>