Dennis Bush

Yes, this was a bug introduced in the most recent version. There was an update to fix a memory leak, but the fix wasn't applied correctly. I'll send out an updated release soon.

Vit, Thanks for catching this. I've just released version 5.0.2 to address this issue as well as some memory leaks recently uncovered. Regards, Dennis

René, Thanks for catching this. I'll include it in the next release. Regards, Dennis

Yes, that is a bug. The comparisons should each be == instead of !=. I'll fix that as well. The conditions that follow those lines are correct.

Vit, Thanks for the patches. Most of these I can include as is (with minor formatting changes). The changes to the advertised GRTT will need a little refactoring. One thing in particular I might do with that is to make the inter-packet wait time the lower limit on the advertised GRTT rather than just adding to it. That should still be enough for your use case while preventing any potential adverse affects on higher transfer speeds. As for the issue of interfaces going up and down, there's probably...

Start by running Wireshark on both the sending and receiving machine to see if the packets are appearing on the local interfaces.

Yes, the change to the -r option sets the minimum round trip to 0.5 seconds, and adjusting that value (specifically the second one) will help reduce the overall time.

Regarding the "incorrect file_id" message, each file in a session is assigned a sequential number starting with 1. This message is printed when a message comes in related to one file which is different from the active file. It's not uncommon to see this message when the invalid file_id is for the prior file, but the fact that the file_id you're seeing is far off from the current file and in some cases larger is concerning. I'm almost positive that the disk spikes are coming from some unrelated process...