CLI documentation / usability / default values

[Mitmischer]

Just a few minor things concerning the CLI help and some usability / default value stuff. More like a collection of things here.

Concerning the help:

• -n has default floor(log(cores)*2)+1, but is that log10 or log2?
• -s says it has default 64M, but as a user I cannot give mscp the number with units - I have to specify bytes. I'd like to be able to put something like -s 4M myself.
• What are the allowed values for -g, -c, -M?

Concerning usability:

• When the values for -s and -S are not divisible by 4096, mscp will give an error and exit. Can't it just round to the next allowed value?
• Just a minor thing, but why does mscp not create the directory needed for -W itself?
• Also, it would be great if I could just specify a flag and mscp would take care of the checkpoints automatically (maybe by making a properly named temporary folder? unison does just that. I don't know if the rsync way (--partial --append-verify) would work for mscp too. Browsers like chrome just leave unfinished downloads as they are, but they get an extension that signals incompleteness (.crdownload). What I like about all those ideas is that they happen automatically, increasing user friendlyness).
• This might be an oversight on my side, but I specified my login name as user@host. What is -l for?

Concercing the default values:

• MAX_CHUNK_SIZE is very large. For a file of hundreds of gigabytes, the transfer is not really interruptible with such a large chunk size (it would have to start over). The minimum chunk size is also relatively large. Wouldn't 16MB/32MB be more reasonable? I'm getting good performance with those and have a quite interruptible transmission.
• Also, for my use case (a high-bandwidth high-latency connection), the number of connections is much more important that the number of ssh connections. In fact, I get full saturation with just -u 1 (but -n 12). The other way round (-u 12 -n 1), I get just plain rsync/scp performance which is horribly slow. The default values however seem to prefer high ssh connection count but low connection count. That does not really cater to the intended audience.

All in all, thank you for your software that makes my transfers fast again. I like it a lot despite the flood of tickets I reported.

[upa]

Thank you for the feedback! will handle it.

[upa]

-n has default floor(log(cores)*2)+1, but is that log10 or log2?

e. See man 3 log.

-s says it has default 64M, but as a user I cannot give mscp the number with units - I have to specify bytes. I'd like to be able to put something like -s 4M myself.

-s, -S, and -b options now accept [kKmMgG] units.

What are the allowed values for -g, -c, -M?

Available ciphers and hmacs are now printed in mscp -h. Available congestion control algorithms are listed in sysctl net.ipv4.tcp_allowed_congestion_control; I added this point to the mscp manpage.

When the values for -s and -S are not divisible by 4096, mscp will give an error and exit. Can't it just round to the next allowed value?

mscp now accepts arbitrary integers for -s and -S.

Just a minor thing, but why does mscp not create the directory needed for -W itself?

IMHO, it is an intuitive/common behavior that program does not create directories automatically, like cp.

Also, it would be great if I could just specify a flag and mscp would take care of the checkpoints automatically (maybe by making a properly named temporary folder? unison does just that. I don't know if the rsync way (--partial --append-verify) would work for mscp too. Browsers like chrome just leave unfinished downloads as they are, but they get an extension that signals incompleteness (.crdownload). What I like about all those ideas is that they happen automatically, increasing user friendlyness).

There are several design choices and implementation considerations. I will consider it separately from this issue.

This might be an oversight on my side, but I specified my login name as user@host. What is -l for?

Both user@host and -l can specify username, as with the ssh command. -l is prioritized in mscp.

MAX_CHUNK_SIZE is very large. For a file of hundreds of gigabytes, the transfer is not really interruptible with such a large chunk size (it would have to start over).

I understand. The default MAX_CHUNK_SIZE is now filesize / (nr_conn * 4).

The minimum chunk size is also relatively large. Wouldn't 16MB/32MB be more reasonable?

Now it is changed to 16MB.

Also, for my use case (a high-bandwidth high-latency connection), the number of connections is much more important that the number of ssh connections. In fact, I get full saturation with just -u 1 (but -n 12). The other way round (-u 12 -n 1), I get just plain rsync/scp performance which is horribly slow. The default values however seem to prefer high ssh connection count but low connection count. That does not really cater to the intended audience.

I guess you misunderstand -u option. man sshd_config states:

     MaxStartups
             Specifies the maximum number of concurrent unauthenticated connections to
             the SSH daemon.  Additional connections will be dropped until authentica‐
             tion succeeds or the LoginGraceTime expires for a connection.  The default
             is 10:30:100.

-u option does not limits the total number of connections; it limits the number of concurrent unauthenticated SSH connection attempts to prevent sshd from dropping new ssh connection attempts by MaxStartups. I have bit improved the help and manpage.

[upa]

All fixes were pushed to the dev branch and not in the main at present. If you have no significant concerns, I will make a new release at an early date (because the current resume transfer is broken as mentioned by #16.

[upa]

v0.2.1 including those changes has been released. Thanks again for the feedback!