Server version of Hercules #10
Conversation
split hercules into a server (C) and monitor (go) process
checked common section checked receiver section checked sender section
This reverts commit 5b50898.
For large files and with many lost packets, the number of ACK packets reuquired to convey all ACK ranges can grow too large, leading to the sender receiving more ACKs than it can process. Change ACK sending as follows: Acks are still sent at a regular interval, but only up to 5 packets at once. Acks sent in the next interval pick up where the previous one left off, so acks now "loop" over multiple intervals.
There was a problem hiding this comment.
Thanks Marco for opening this PR!
I looked through the documentation (and only the documentation) and found a few typos.
Note that I commented on the Markdown files instead of the manual files as they were easier to read. So probably you will update the manual files and then just rebuild the Markdown files.
Hope this helps.
spotted by Aaron, thanks!
marcopioppini
force-pushed
the
server
branch
from
f7b9d70 to
7b87319
Compare
| @@ -0,0 +1,3 @@ | |||
| You may use the service files provided here to run hercules via systemd. | |||
| Make sure to replace the executable path and working directory according to your installation and copy the files to the appropriate location on your system. | |||
| The files should take care of starting and stopping the hercules server and monitor together. | |||
There was a problem hiding this comment.
The files should take care of starting and stopping the hercules server and monitor together.
Do we document the inter-dependencies? The hercules-server relies on the monitor to get paths, but why would it be an issues for example to restart the hercules-server without also restarting the monitor? The monitor doesn't reconnect?
There was a problem hiding this comment.
They should not be restarted independently, as mentioned in the main readme.
Unfortunately, I did not get around to implementing this. Currently there are two main issues:
Because the server always sends requests to the monitor and waits for the reply (blocking), if you were to restart the monitor at the wrong time (before it was able to answer a pending request), the server could get stuck. Also, restarting only one of the two may mess up their shared state (which transfer ids exist, what transfers do they refer to, what state are they in, etc.).
Co-authored-by: FR4NK-W <[email protected]>
This changes Hercules from a 1 transfer at-a-time tool to a long-running server.