ioFTPD v7.5.9 Released (Beta)

[BoNeZz]

Originally Posted by Yil

NULL? I think that means it would be plaintext without any encryption at all. I can't think of a good reason why that would slow things down! Can you see what cipher (if any) it thinks you are connecting to the server with?

Can you double check that no-SSL and SSL to the same site back to back result in a huge performance difference? Is that true of all sites? Perhaps it's the other side that is slow and not you...

i can't see what chiper have other side, but it is drftpd that support tls, ssl in fxp

there isn't performance difference if i try to upload in ioftpd from the same site with and not ssl

the only difference is download from ioftpd in local, with ssl bad speed, without ssl full speed

the source site\s are 100mbits, and destination is my ioftpd 10mbits

if i try to upload from this site 100mbits drftpd to ioftpd in win7 quadcore, speed is good, and also from ioftpd to 100mbits

i tried with others 100mbits with glftpd, but same problem speed in fxp (from glftpd to ioftpd) of course also from ioftpd to glftpd, speed is too slow.

[Yil]

I'm not sure I understand what you are saying... Could you try to explain each test again? Also, just for comparison, could you use an FTP client and download with and without SSL to the same machine directly? That should help make it clear if the other side is slowing things down.

[BoNeZz]

Originally Posted by Yil

I'm not sure I understand what you are saying... Could you try to explain each test again? Also, just for comparison, could you use an FTP client and download with and without SSL to the same machine directly? That should help make it clear if the other side is slowing things down.

monocore cpu:
WinXP Professional Service Pack 3 32bit
AMD Sempron 2400+ or AMD Athlon 64 processor 3500+

test1: ioFTPD 7.5.9 in monocore cpu machine and fiber 10mbits up\dn, download from it with ftprush with my 4mbits dsl in ssl, i get 250kb/s speed, too slow, should be 500kb/s (full speed for my dsl)

test2: ioFTPD 7.5.9 in monocore cpu machine and fiber 10mbits up\dn, download from it with ftprush with my 4mbits dsl WITHOUT ssl, i get 500kb/s speed, so full speed for my dsl

test3: ioFTPD 7.5.9 in monocore cpu machine and fiber 10mbits up\dn, FXP from a drftpd or glftpd with 100mbits fiber, in ssl and WITHOUT ssl or tls, i get 50% of total bandwith, like 500kb/s, it should be 900kb/s or 1mb/s ( that's the 100% of 10mbits fiber )

i tried also to download from ioFTPD 7.5.9 in monocore cpu machine and fiber 10mbits up\dn TO 100mbit glftpd or drftpd with and without ssl or tls, but same speed, 50% of total bandwith, so 500kb/s, not 900kb/s or 1mb/s


test4: ioFTPD 7.5.9 in quadcore machine like INTEL Q6600 2,4Ghz, same ioftpd.ini config and same scripts ( ioA, ioninja, nxtools )
-download in local with ftprush with my dsl 4mbit, with ssl and without ssl, make full speed like 500kb/s
-fxp from or to this ioFTPD 7.5.9 in quadcore machine, make full speed like 900kb/s 1mb/s, so very close at 90% of total bandwith

ioFTPD 7.5.9 in quadcore machine have WIN7 64bit

[Yil]

BoNeZz: OK, I think I have an idea of what might be happening on single core machines and probably in other cases where there are more active transfers than logical cores.

The I/O threads send/receive all data and prior to v7.4 they would hand off the actual CPU-intensive encryption/decryption to another thread. With the change to OpenSSL and the high-performance non-copying BIO interface it became trickier to pass the work off to another thread so I opted to just do it when I got the data and figured I'd save the overhead of a few context switches and a bunch of other crap in the process. The request for new data from the socket wouldn't occur until after all the processing was done in either case and the kernel just buffers any new TCP data arriving. With this setup the total CPU time will indeed be less but it appears I forgot to take into account what the higher priority of the I/O thread might do to the rest of the computer. It's possible that hogging the CPU in such a way changes the system responsiveness. This is particularly hard to judge when a network and a remote machine feedback into everything. Subtle changes to the timing of sending network ACKs, etc can effect max bandwidth...

If during your tests you were the ONLY user downloading from the FTP I don't think there should be much of a difference on a single core machine. Perhaps you could double check that just to see if that matters?

However, I can now theorize why 2+ users downloading/uploading on a single core machine might see a difference between v7.3 and v7.5. It probably doesn't help that OpenSSL got stronger (and slower) encryption ciphers.

I'm not sure what the best solution is. I'll probably try playing with the priority of the I/O threads depending upon what they are doing. So before encryption/decryption they would go back to normal priority which means the other I/O threads would be favored. This would approximate the old behavior provided you doubled the number of I/O threads. Doing that now won't really hurt, but it won't help too much because they would all be at the same higher priority right now...

This is an interesting phenomenon, and one I didn't think of or see in any of my tests with my core i7 and it's 8 logical cores Thanks for bringing it to my attention.

[Yil]

BoNeZz: Here's a new .exe that plays with the priority around the CPU-intensive encrypt/decrypt. I can't say I've tested this at all, but give it a try and see if there is a difference... Remember to up the number of I/O threads to at least 4.

Link: ioFTPD-v7.5.10-exe-only.zip

[BoNeZz]

Originally Posted by Yil

BoNeZz: Here's a new .exe that plays with the priority around the CPU-intensive encrypt/decrypt. I can't say I've tested this at all, but give it a try and see if there is a difference... Remember to up the number of I/O threads to at least 4.

Link: ioFTPD-v7.5.10-exe-only.zip

very nice!!!

with io_threads 4

without ssl:
(16:53:37) [i] file.r02 47,7 Mbytes/56,80(s)/880,28Kbps
(16:54:55) [i] file.r03 47,7 Mbytes/01:07(s)/742,09Kbps
(16:55:57) [i] file.r04 47,7 Mbytes/01:01(s)/825,21Kbps
(16:57:06) [i] file.r05 47,7 Mbytes/01:08(s)/729,93Kbps
(16:58:03) [i] file.r06 47,7 Mbytes/56,46(s)/885,63Kbps

with ssl:
(16:59:19) [i] file.r07 47,7 Mbytes/01:05(s)/773,43Kbps
(17:00:17) [i] file.r08 47,7 Mbytes/56,57(s)/883,92Kbps
(17:01:23) [i] file.r09 47,7 Mbytes/01:06(s)/757,53Kbps
(17:02:21) [i] file.r10 47,7 Mbytes/56,60(s)/883,44Kbps

so same speed, nice

i don't know if is possible make more speed and more stable, because you can see a file at 700 and next at 800, etc...

i tried to with io_threads 6 but same speed ( that now is too nice )

i tried now drctp and tcpoptimizer with some settings to see if it's possible increase speed to lan or only ioftpd

[Yil]

BoNeZz: Glad to hear that the simple fix worked for you!

Optimizing TCP speeds is an art, not a science if you ask me. TCP buffer size, frame size, window size, delays, Nagel, etc all impact speeds and optimizing it for a particular internet route may totally destroy bandwidth to/from someone else... I'd be careful with too many adjustments.

When talking about internet routes with many hops you won't get reproducible results. You'll just have to average a few runs and too many tests over a long time frame probably introduces time into the equation since different times of day probably get different speeds especially on things like residential cable lines.

[rastamanx]

FXP GLFTPD to IOFTPD 7.5.10 :

[GLFTPD] CPSV
[GLFTPD] 227 Entering Passive Mode (xxx,xxx,xxx,xxx,174,0)
[IOFTPD] PORT xxx,xxx,xxx,xxx,174,0
[IOFTPD] 200 PORT command successful.
[IOFTPD] STOR file.r00
[IOFTPD] 150 Opening BINARY mode data connection for file.r00 using SSL/TLS.
[GLFTPD] RETR file.r00
[GLFTPD] 150 Opening BINARY mode data connection for file.r00 (50000000 bytes).
[GLFTPD] 435 Failed TLS negotiation on data channel (using SSL_connect()), disconnected: Connection reset by peer.
[IOFTPD] 426 Connection closed: SSL library failure (error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number).

Any idea ?
Is this an openssl version conflict/incompatibility on my box ? Or between gl ssl libs and io ssl libs ?
Is there a magic SSL setting in the openssl settings that I missed ? =)

[BoNeZz]

Originally Posted by rastamanx

FXP GLFTPD to IOFTPD 7.5.10 :

[GLFTPD] CPSV
[GLFTPD] 227 Entering Passive Mode (xxx,xxx,xxx,xxx,174,0)
[IOFTPD] PORT xxx,xxx,xxx,xxx,174,0
[IOFTPD] 200 PORT command successful.
[IOFTPD] STOR file.r00
[IOFTPD] 150 Opening BINARY mode data connection for file.r00 using SSL/TLS.
[GLFTPD] RETR file.r00
[GLFTPD] 150 Opening BINARY mode data connection for file.r00 (50000000 bytes).
[GLFTPD] 435 Failed TLS negotiation on data channel (using SSL_connect()), disconnected: Connection reset by peer.
[IOFTPD] 426 Connection closed: SSL library failure (error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number).

Any idea ?
Is this an openssl version conflict/incompatibility on my box ? Or between gl ssl libs and io ssl libs ?
Is there a magic SSL setting in the openssl settings that I missed ? =)

on ioftpd.ini is like that?
;Encryption_Protocol = TLS
OpenSSL_Options = ALL

try to see these options, im not sure but maybe you have the first option enable, so comment it

[rastamanx]

Indeed.
Enforcing TLS doesn't look like such a good idea heh
Thanks BoNeZz.

By the way, Yil if you're around, when a file fail to transfer for this reason, or another (I've witnessed the same behaviour when PASV transfer fails), I end up with a 0b file, UNDELETABLE.

If i try to delete it from my ftp client I got :
250 DELE command successful.
But it's still here.
If I try to delete it again, I got :
550 file.zip: No such file or directory.
If I check from within Windows explorer, the file is still there, and I need admin perms to delete it.
Now, if it is a good day, I manage to delete it with admin rights.
If it is a bad day, the file is read/write locked, and I must kill ioftpd.exe first.
So if you could do something to unlock failed files after error output somewhere, it would be nice.

[Yil]

An undeletable file huh? Use "site swho" and see if there isn't some connection stuck trying to upload the file or something. I've seen zipscripts (especially the .exe variety) get stuck before and that would leave the file with an open handle or two. It also occurs to me that the internal ioFTPD-only read/write lock on the file only applies to the files contents and it could probably be "deleted" but exactly when depends on how windows handles open files being deleted. Just for kicks try to upload the file again while it's in this weird state and carefully record the error message.

If you were using "Encryption_Protocol = TLS" then you do limit yourself to a pure TLS handshake for logging in and data transfers. There's even a warning that if you do set this you'll probably have to tweak some other settings. I suggest you leave it commented out

[Yil]

Well, I went to look at the changes for the async rewrite and forgot some of things I knew were important when I was last working on it and decided to bail on it for a bit. So I did the next best thing. I forked the code, removed the async changes, and started working on a new release without it. I think I previously mentioned some of the things to look forward to like the 'site flags' command, FXP transfer speed updates during the transfer, etc. I've got a rather disorganized to-do/note file and I might pull out a few things from it.

So, if you know of an issue, want to suggest a new feature, or just want to prioritize a feature request by letting me know it's important, feel free to chime in now...

[Pjevser]

I have a tiny problem with ioftpd and logging, it doesn't write the name complete.

ex: Lets say i want to upload "Test" then when i look in ioftpd.log it will write it as:

NEWDIR: "USER" "ioftpd" "//est" "D:\FTP\test"

And that it does for every thing i upload, it removes the first letter in the name and replace it with a /

I have no idea why, so anyone got any ideas?

[Yil]

Two things come to mind. The first and most likely is something isn't quite right with the .vfs file. Since it looks like it's happening at the root level, i.e. /test, it must be the root entry. Double check the / mountpoint.... If '/test' is a mountpoint double check that entry as well, and/or verify a regular dir in root works OK.

The only other thing is something weird like the root directory got turned into a symlink or something. Try removing the .ioFTPD file in the root dir and see if that makes the problem go away.

[Yil]

Looking for some feedback on a possible new feature...

I've seen FTP servers setup where access to things like "site who", "site stats", etc are all restricted to Admins only. I can understand the reasoning, but often the filesystem goes ahead and displays the owner/group on everything and I just have to scratch my head and wonder why do they bother... I'm assuming that people set it up that way intentionally so perhaps there is interest in something better.

The idea I have only applies to non-Admins and looks something like this:

Anonymize_Users option -- users who match this setting have their usernames replaced with something (determined by Anonymize_Style below) so that all filesystem ownership information in directory listings and site commands such as 'site who' and 'site stats' will not disclose their username. In no case will the user's own information be hidden from themselves so they can determine their stats ranking and see what they are doing on another login via site who, etc.

Anonymize_Style is one of "<hidden>", "UID", "GID", or "<group>". "<hidden>" shows just that string, "UID" shows "UID:###" where # is the numeric user-id of the user, GID shows "GID:###" where # is the numeric group-id of the primary group of the user, and "<group>" shows "<groupname>" with the <>'s. The advantage of using something other than "<hidden>" is that it is more interesting to view the stats of anonymized users over time, or to see that a particular user is uploading/downloading several things at once even if you don't know who they are. These seem reasonable? I haven't seen what this stuff looks like in directory listings yet so something shorter than the UID: prefix might make sense... Like #34 or something. But it can't just be a number since that would be a valid username...

I'm also thinking of adding a userflag, groupflag, or something that would prevent anonyimzing users who are in the same primary group (provided it isn't NoGroup). Thus you could enable certain subsets of users, if you wanted, to see other users in their primary group by name but everyone else would be anonymized.


Is this a feature you would find useful? Got any suggestions on ways to improve it?