--throttleupload option has no effect

[raimocom]

Describe the bug

The --throttleUpload option doesn´t seem to throttle the upload speed.

To Reproduce

Steps to reproduce the behavior:

1. (Sending side) croc --throttleUpload 500k send --code SECRET-CODE-PASS BigFile.zip
2. (Receiving side) croc --code SECRET-CODE-PASS --> observed download speed way higher than 500k (in this case 2MByte/s)

Expected behaviour

Max. upload speed of 500kByte/s

Version

10.0.7

Operating system

Windows 10

[schollz]

how are you measuring the download speed?

[raimocom]

I don't. I'm observing the speed and remaining time output of croc at the sending side.

[schollz]

The observed speed and remaining time output of croc is related to the original bytes transferred, which is not the same as the bandwidth usage, because of compression.

[raimocom]

I'm transferring a 7z archive, maximum compression. So croc's internal compression has nothing to further compress. So original bytes = bandwith usage, right?

One added observation: --throttleUpload has an effect, but an unintended one. It reliably and reproducibly delays the start of the file transfer

• --throttleUpload 50000k -> transfer starts after ca. 3 seconds
• --throttleUpload 5000k -> transfer starts after ca. 30 seconds
• --throttleUpload 500k -> transfer starts after around 6 minutes

(all times after FILENAME 0% | | ( 0 B/14 GB) [0s:0s] is displayed)

After the download has started, the bandwith usage is always equal to without using --throttleUpload

• croc send run on a Windows 10 PC
• croc receive (why does this command not exist?) runs on a Linux Mint PC

[schollz]

sounds like a bug then, will happily take a pr.

croc receive (why does this command not exist?)

croc receive does not exist, because, on Windows, you can then receive a file just by double-clicking the croc executable (because receiving requires no command line arguments for basic case).

[raimocom]

sounds like a bug then, will happily take a pr.

O well, that is way outside my very humble abilities unfortunately.

croc receive (why does this command not exist?)

croc receive does not exist, because, on Windows, you can then receive a file just by double-clicking the croc executable (because receiving requires no command line arguments for basic case).

You could keep current behaviour and add a (functionalitywise superfluous) receive command. That would make it a cleaner user interface (one command for every usage scenario) and self explanatory command lines.

[schollz]

You could keep current behaviour and add a (functionalitywise superfluous) receive command.

happy to accept a pr

[tnothy]

I believe the invalid throttling is related to this line

rt = rate.Every(time.Second / (4 * time.Duration(uploadLimit)))

After removing the 4 * part, the upload speed seems to be as expected. However, I am unsure why the 4 * was included initially.

[schollz]

perfect, submit a PR and I can include it in the next release