Today. Today was a day full of a lot of freeciv. I did however get a bit of auditing on the ftpd done. Didn't find anything of extraordinary importance, just went through and came up with a few possibilities of what shouldn't happen but could happen. Tomorrow, I'll try them out and look through the main processing loop of the program. See if there is anyway to tighten it up any. I kept glancing through a few secure coding articles to try to come up with ways it could break.(Including Securing programming howto by d.wheeler)

Ahh..well..I will find out how to break it. Can't wait.

Laters

Ahhh! After 5 months of Stress, it's finished. I've been working with a sports-drink company developing an application to deal with their customers, orders and manufacturing.

Now, maybe I'll have some time to relax and code this ftp server. Got a few good books that I might read.

The ftp server has been on the side-lines for those 5 months and so now it needs to be audited and tested. I've run it with a few different clients. Opera, netscape, mozilla, internet explorer, windows explorer, and gftp. Out of all those, mozilla was a pain in the ass. Nothing extradionary but it's not particulary good at ftping. For instance, when opening a connection it calls out RETR /
What ftp client needs to download the root directory?! Obviously, that command fails and mozilla completes a login. Anyway, that's been the only glitch outside of having to rewrite some of the ls/dir/listing code.
I'm yet to really attack the server outside of normal high-connection stress testing. It hasn't been tested with perverted usage yet.
On my celeron 533/192MB box, I'm getting ~300 connections per second and that is with the benchmarking tool running at the same time. Which is around 25 million connections per day. Not too bad for something that I'm yet to really try to optimise.
Due to the poll implementation, it probably will only be able to handle 1000-3000 users concurrently. I've looked into io signal events in linux for handling the sockets but its quite poor. Because in a heavy loaded server, you have to fall back on poll to fix up the queue when it overruns.(This happens regularly)
You are trying to get away from poll() because of lack of scalability but under the current methods you have to use it when the machine's load is at its worst.

Anyway, laters..

Getting frustrated with poll(), dkftpbench, and some elusive bugs?!
I looked at using RT signals for my server but the whole, falling back
on poll in an overloaded state, it's crap.
Guess I'll have to wait for /dev/poll/epoll to hit mainstream kernels or
a kqueue/kevent setup to be implemented in linux.

Seriously, looking at writing some documentation for the FOX toolkit.