CLI documentation / usability / default values about mscp

[upa]

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

[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.