From owner-freebsd-hackers Mon Dec 1 14:33:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26378 for hackers-outgoing; Mon, 1 Dec 1997 14:33:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dns (dns.ida.net [204.228.203.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA26373 for ; Mon, 1 Dec 1997 14:33:48 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (pm-if3-4.ida.net [204.228.203.163]) by dns (SMI-8.6/mail.byaddr) with SMTP id PAA15389; Mon, 1 Dec 1997 15:25:54 -0700 Date: Mon, 1 Dec 1997 15:31:16 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Amancio Hasty Jr cc: hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com In-Reply-To: <199712012138.NAA03509@netcom14.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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)