LordM: interesting. Have you seen that behavior without SSL? I wonder if the key exchange or something had an issue. I'll look at the code since I'm not sure any sort of timeout applies to ioFTPD sending data and thus if the exchange fails ioFTPD might just get stuck until the client closes the connection. In this case it looks like the client closed or lost the control connection as well. I'm pretty sure ioFTPD won't ever time you out on the control connection if you have an active data transfer in progress though so I'm inclined to think the client just closed both...
zOrP, oldhouse: If you can explain how this works in detail I'll see what I can do. I'm guessing you would need to scan all the user accounts, compile a list of allowed IP masks and then apply that combined list before accepting any connections. That's doable I guess. On the other hand a single user with *@* would turn the feature off right? Also, names would need to be resolved every once in a while to keep them fresh...
.ioFTPD: The 4k buffer created on the stack can turn into a dynamically allocated memory buffer for larger blocksizes and I missed realizing what was happening. There is however a hard 128k blocksize limit in the code right now but if you have 128k of FileContext for a directory I think there's a problem hehe...
pretorian: There really isn't any way to disable directory caching because it's a good thing. Any FTP that allows fine grained permissions for files like ioFTPD or Raiden needs to store those settings somewhere and apply them to files when testing for access rights. Unix FTP servers often just use the actual file/group permissions of the files and thus don't need any extra data but Window's FTP servers with file level rights do. Since there is a really high chance of a CWD being followed by a LIST the parsing of permission info really can't be avoided in most cases and keeping that work done is a good thing. Notice the time it takes to enter a big directory the first time versus the second. I should point out that some of that time is actually the OS having to cache directory information itself.
The only way to significantly improve performance would be to store directory permission information in the parent folder instead of the actual folder. Or perhaps more accurately in both places. This would prevent having to actually examine every .ioFTPD file in every subdir to get the permission/ownership information. That's a pretty substantial change though.
The new option I added to speed up CWD and directory listings essentially inlines the subdirectory .ioFTPD lookup and limits it to just parsing the subdirectory permissions instead of enumerating all the files in the subdir and then applying all the permissions. I did take one further shortcut. I also don't compute the CRC checksum for the .ioFTPD file when examining it just for listings. I might go back and add that or make it an option just to be safe, but when you actually enter or access files in the subdirectory the original code is still used which verifies the file.
Flow: I think I've added all the options I was complaining that ioFTPD didn't have and wanted. If you've got new ideas feel free to bring them up. Besides the lack of a front end I think ioFTPD gives all the other Window's FTP servers a run for their money and the cost is hard to beat now
A new Windows based GUI sounds really good to me, but in my opinion it should be a standalone type thing and issue all commands through the FTP server like ioGUI does. Not using shared memory takes a performance hit but allows you to administer FTP servers that aren't local and that would be a good thing. I haven't played with the VS2005 GUI builder but mocking up the screens and getting the interface right sounds like a good place to start. The other big thing here is we aren't limited to using what ioFTPD provides today. I can easily add an event driven model where transfer updates, issued commands, etc are pushed to the GUI over a data connection instead of having the front end poll every second like it does now... I also thought the front end should NOT handle server configuration (that's just too complicated) BUT should allow non-master accounts as well. Thus group admins could modify their users with a GUI...
The only other thing on my list was to look into what a real windows service application looks like. I don't know if you have to do anything special or not but a service installer would be useful and using the auto-restart logic that comes with Window's services is nice.
Tuff and Yil
Linear Mode
