From 352d58d7f815a91208e114dbc7147737c3d39efb Mon Sep 17 00:00:00 2001 From: sgunderson Date: Tue, 25 Jul 2000 23:52:37 +0000 Subject: [PATCH] Re-indenting, homepage changed. --- README | 150 +++++++++++++++++++++++++++------------------------------ 1 file changed, 71 insertions(+), 79 deletions(-) diff --git a/README b/README index 1c03da5..760a1aa 100644 --- a/README +++ b/README @@ -24,9 +24,8 @@ BetaFTPD uses GNU autoconf. Just type: ./configure make -And see what happens. (Run the resulting file called `betaftpd', of -course...) There are some flags that you can (and probably want to) give -to `configure': +And see what happens. (Run the resulting file called `betaftpd', of course...) +There are some flags that you can (and probably want to) give to `configure': --enable-xferlog Makes the server output some logging information to /var/log/xferlog (or /usr/adm/xferlog if that fails). @@ -65,9 +64,9 @@ to `configure': and .message files are printed every time the user enters the directory, even if he/she has been there before. -To get the smallest executable possible, _first_ check everything -in `strip-exec' (it's unsupported -- don't complain to me if it doesn't -work, fix it yourself! :-) ), and type: +To get the smallest executable possible, _first_ check everything in +`strip-exec' (it's unsupported -- don't complain to me if it doesn't work, fix +it yourself! :-) ), and type: strip-exec @@ -75,99 +74,92 @@ strip-exec ---------------------- a) BetaFTPD now listen on port 21 by default (it used to run on port 121). To change it, change FTP_PORT in ftpd.h to whatever you'd like it to listen on. -b) BetaFTPD must definitely be run as root (unless you use --enable-nonroot - as mentioned above). +b) BetaFTPD must definitely be run as root (unless you use --enable-nonroot as + mentioned above). c) Some commands and features are missing, but probably not many that you'd really miss. See the KNOWN-BUGS and RFC-COMPLIANCE files. d) BetaFTPD can _not_ be run from inetd. This is a design decision. 4. Design decisions ------------------- -BetaFTPD was originally designed to be a single-threaded FTP server, -nothing else. After a while, work was done to reduce the executable size, -and from then, design was more and more concentrated around a -`minimalistic' server (after all, the fewer lines of code there are to -execute, the faster will things go, and the fewer bugs are possible). - -However, as GNU autoconf support was added, it was realized that -features could be added and selected by users without hurting overall -speed or size for the others. Therefore, more and more features are -(and will be) implemented in BetaFTPD. - -There are intendedly no command line switches it BetaFTPD. Such switches -are generally there to make for quick change of options without -recompiling the program. This is ideal for most command-line utilities, -but is rather pointless for an FTP server. FTP servers are designed -to be online 24 hours a day, 7 days a week, and serve users with files. -Rapid confiuration changes (in the form of command line switches, -configuration files et al) are usually not important, and has thus been -omitted from BetaFTPD. - -There is no (and will never be a) ratio function in BetaFTPD, as such -features are only used for warez/MP3/porn servers, and are quite stupid -even then. +BetaFTPD was originally designed to be a single-threaded FTP server, nothing +else. After a while, work was done to reduce the executable size, and from +then, design was more and more concentrated around a `minimalistic' server +(after all, the fewer lines of code there are to execute, the faster will +things go, and the fewer bugs are possible). + +However, as GNU autoconf support was added, it was realized that features could +be added and selected by users without hurting overall speed or size for the +others. Therefore, more and more features are (and will be) implemented in +BetaFTPD. + +There are intendedly no command line switches it BetaFTPD. Such switches are +generally there to make for quick change of options without recompiling the +program. This is ideal for most command-line utilities, but is rather pointless +for an FTP server. FTP servers are designed to be online 24 hours a day, 7 days +a week, and serve users with files. Rapid confiuration changes (in the form of +command line switches, configuration files et al) are usually not important, +and has thus been omitted from BetaFTPD. + +There is no (and will never be a) ratio function in BetaFTPD, as such features +are only used for warez/MP3/porn servers, and are quite stupid even then. 5. Eek! `top' says BetaFTPD uses tons of memory! ------------------------------------------------ -Yes, but top really is wrong :-) Well, actually, I don't think it could -do better -- every file BetaFTPD mmap()s is counted towards the total -number. So if you were serving the same 128MB file 10 times, top would -claim you used over a gigabyte of memory, still only a couple of -megabytes would be used at most, as cache. If you ran out of memory, -this could actually shrink to zero. It's just that the kernel tries to -be more effective (and it succeeds) by reducing the number of reads, and -instead reading larger chunks at once. - -If sendfile() support is enabled, and the circumstances allow it (binary -mode downloading), BetaFTPD will not mmap() at all, bringing the memory -total down to a more realistic value. +Yes, but top really is wrong :-) Well, actually, I don't think it could do +better -- every file BetaFTPD mmap()s is counted towards the total number. So +if you were serving the same 128MB file 10 times, top would claim you used over +a gigabyte of memory, still only a couple of megabytes would be used at most, +as cache. If you ran out of memory, this could actually shrink to zero. It's +just that the kernel tries to be more effective (and it succeeds) by reducing +the number of reads, and instead reading larger chunks at once. + +If sendfile() support is enabled, and the circumstances allow it (binary mode +downloading), BetaFTPD will not mmap() at all, bringing the memory total down +to a more realistic value. Bragging: -On my Intel system, every user needs 1104 bytes (`struct conn'). -When a user has a file transfer, an additional 324 bytes (`struct ftran') -would be needed, or 1428 bytes per user in total. In addition, you have -some `startup costs', of course. `ps' (again on my system) reports a -startup memory usage of 432 kB (RSS, I don't know enough about memory -to know if this is a realistic number ;-) ), compared to 484 kB for a -single wu-ftpd session (again RSS). To be honest, I don't think BetaFTPD -uses much memory. [Note that this information is a bit old -- I haven't -tested it lately; expect 2-300 bytes extra per user.] - -Oh, while we're at it: A 486 running BetaFTPD will easily be able to -saturate a T1 line, with room to spare. The bottleneck will most likely -lie somewhere else (like the bandwidth, or how fast the disk can deliver -data). Unless you've got a 386 running gigabit, of course... (I must -admit, I've never really tried it with more than 100Mbit/sec, but the -problem then was clearly on the client machine ;-) BetaFTPD has later -shown itself to be more than able of saturating a 10mbit link in real- -world tests, with about 3% CPU utilization (PII/450MHz, IDE disks all -the way, about 2GB of files in all, 7-8 users at once).) - -Recent load tests (see http://www.kegel.com/dkftpbench/results.html) -show that a P90 is able to serve about 250 clients (each at 28.800-speeds) -on a 10Mbit line. +On my Intel system, every user needs 1104 bytes (`struct conn'). When a user +has a file transfer, an additional 324 bytes (`struct ftran') would be needed, +or 1428 bytes per user in total. In addition, you have some `startup costs', of +course. `ps' (again on my system) reports a startup memory usage of 432 kB +(RSS, I don't know enough about memory to know if this is a realistic number +;-) ), compared to 484 kB for a single wu-ftpd session (again RSS). To be +honest, I don't think BetaFTPD uses much memory. [Note that this information is +a bit old -- I haven't tested it lately; expect 2-300 bytes extra per user.] + +Oh, while we're at it: A 486 running BetaFTPD will easily be able to saturate a +T1 line, with room to spare. The bottleneck will most likely lie somewhere else +(like the bandwidth, or how fast the disk can deliver data). Unless you've got +a 386 running gigabit, of course... (I must admit, I've never really tried it +with more than 100Mbit/sec, but the problem then was clearly on the client +machine ;-) BetaFTPD has later shown itself to be more than able of saturating +a 10mbit link in real- world tests, with about 3% CPU utilization (PII/450MHz, +IDE disks all the way, about 2GB of files in all, 7-8 users at once).) + +Recent load tests (see http://www.kegel.com/dkftpbench/results.html) show that +a P90 is able to serve about 250 clients (each at 28.800-speeds) on a 10Mbit +line. 6. Misc. -------- -Have fun -- after all, it's about 5% the size of wu-ftpd (about 20k -compiled!) and provides (IMHO) about 98% of the needed, everyday -functionality -- in fact, if you don't need the _really_ exotic commands, -it's faster (=better?) and uses *much* less memory (especially when -you have many users logged in at once) than the majority of the FTP -servers out there... (6 line sentence.) - -This program is GPLed, version 2 (see the file COPYING), not any later -or earlier version (later versions will probably `upgrade' to new GPLs -as they become available, I just want to be able to choose what license -I put my code under). For more info on the GPL, visit http://www.gnu.org/ . +Have fun -- after all, it's about 5% the size of wu-ftpd (about 20k compiled!) +and provides (IMHO) about 98% of the needed, everyday functionality -- in fact, +if you don't need the _really_ exotic commands, it's faster (=better?) and uses +*much* less memory (especially when you have many users logged in at once) than +the majority of the FTP servers out there... (6 line sentence.) + +This program is GPLed, version 2 (see the file COPYING), not any later or +earlier version (later versions will probably `upgrade' to new GPLs as they +become available, I just want to be able to choose what license I put my code +under). For more info on the GPL, visit http://www.gnu.org/ . 7. Where to get new versions, contact me etc. --------------------------------------------- E-mail: sgunderson@bigfoot.com (all spam/flame go to antispam@bigfoot.com or /dev/null) -Homepage, new versions: http://members.xoom.com/sneeze/ - (Click the link, and see under Projects.) +Homepage, new versions: http://betaftpd.sourceforge.net/ Mirror site: ftp://metalab.unc.edu/pub/Linux/system/network/daemons/ (Note that Metalab will always lag behind a few days, and doesn't carry beta versions.) -- 2.39.2