Date: Mon, 01 Dec 1997 20:50:47 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: Charles Mott <cmott@srv.net> Cc: Amancio Hasty Jr <hasty@netcom.com>, hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com Message-ID: <199712020450.UAA01727@rah.star-gate.com> In-Reply-To: Your message of "Mon, 01 Dec 1997 15:31:16 MST." <Pine.BSF.3.96.971201150457.9094A-100000@darkstar.home>
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. You can do it as you have suggested also the thing to keep in mind is the cost of per connection and memory. For instance a process context switch plus the over head of a process is not a very efficient mechanism for large scale ftp servers. Have Fun Guys, Amancio > 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 I am not sure if that is an approach implementation issue or an OS issue no matter what the kernel has to keep the state information for connection oriented states for all processes. > 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?199712020450.UAA01727>