Dear all, I like to run rpki-client very often, and not be bogged down with non-responsive respositories. If a repository is uncommunicative, rpki-client as-is will try other transports, or come back later (because of a next crontab invocation).
In rpki-client, RSYNC & HTTPS timeouts now are unified: - if the initial connection can't be established within MAX_CONN_TIMEOUT seconds, try one of: Another Address Family (such as IPv6), or Another Transport Protocol (like RSYNC). - If the remote peer at the other side of the HTTPS or RSYNC connection doens't send us any data for the duration of MAX_IO_TIMEOUT, try one of Another Address Family (such as IPv6), or Another Transport Protocol (like RSYNC). I propose that if the remote side fails to send any new data for the duration of 30 seconds, we should give up, try something else (which includes locally cached data from the previous invocation). I've tested with MAX_IO_TIMEOUT set to 15 seconds; and would feel comfortable committing that; but some in our community expressed hesitance, hence the below proposal for 30. OK? Kind regards, Job Index: extern.h =================================================================== RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v retrieving revision 1.146 diff -u -p -r1.146 extern.h --- extern.h 9 Aug 2022 09:02:26 -0000 1.146 +++ extern.h 10 Aug 2022 02:01:45 -0000 @@ -731,7 +731,7 @@ int mkpathat(int, const char *); #define MAX_CONN_TIMEOUT 15 /* How long to wait for IO from a remote server. */ -#define MAX_IO_TIMEOUT 180 +#define MAX_IO_TIMEOUT 30 /* Maximum allowd repositories per tal */ #define MAX_REPO_PER_TAL 1000
