schollz
--throttleupload option has no effect
Describe the bug
The --throttleUpload option doesn´t seem to throttle the upload speed.
To Reproduce
Steps to reproduce the behavior:
- (Sending side)
croc --throttleUpload 500k send --code SECRET-CODE-PASS BigFile.zip - (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
I don't. I'm observing the speed and remaining time output of croc at the sending side.
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.
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
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).
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 receivedoes 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.
You could keep current behaviour and add a (functionalitywise superfluous) receive command.
happy to accept a pr
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.
