Feature: Connection timeouts, retries, and keepalive #180

New Issue

2026-07-30T18:32:18+02:00

TapTap commented

2026-07-30 18:32:18 +02:00

Corresponding rsync flags/behavior:

--timeout=SECONDS — I/O timeout
--contimeout=SECONDS — connection timeout
--retries=N — number of attempted retries for a failed connection

Current FastSync behavior:
src/shared/transport_tcp.c creates blocking sockets with no timeout. receive_n_data() in src/shared/protocol.c can block forever on a stalled connection. There are no TCP keepalive options and no retry logic.

Proposed changes:

CLI flags: --timeout=<sec>, --contimeout=<sec>, --retries=<n>
Config fields: int io_timeout_sec, int connect_timeout_sec, int connect_retries
Implementation:
- Use SO_RCVTIMEO/SO_SNDTIMEO or poll() with timeout in send_n_data/receive_n_data
- Apply SO_KEEPALIVE and optional TCP_USER_TIMEOUT on Linux
- Retry TCP/SSH connection up to --retries with exponential backoff
- For SSH transport, detect failed execvp (already partially handled via exec_pipe) and retry
Protocol: no wire changes; client-side robustness only

Priority: high
Rationale: Without timeouts, a single hung connection can stall a sync job indefinitely. Retries are essential for automation over unreliable networks.

Acceptance criteria:

--timeout=30 causes a stalled receive to error out after 30 seconds
--contimeout=10 fails fast when the server is unreachable
--retries=3 attempts the connection three times before failing
Integration tests simulate slow/stalled server and verify timeout behavior

**Corresponding rsync flags/behavior:** - `--timeout=SECONDS` — I/O timeout - `--contimeout=SECONDS` — connection timeout - `--retries=N` — number of attempted retries for a failed connection **Current FastSync behavior:** `src/shared/transport_tcp.c` creates blocking sockets with no timeout. `receive_n_data()` in `src/shared/protocol.c` can block forever on a stalled connection. There are no TCP keepalive options and no retry logic. **Proposed changes:** - CLI flags: `--timeout=<sec>`, `--contimeout=<sec>`, `--retries=<n>` - Config fields: `int io_timeout_sec`, `int connect_timeout_sec`, `int connect_retries` - Implementation: - Use `SO_RCVTIMEO`/`SO_SNDTIMEO` or `poll()` with timeout in `send_n_data`/`receive_n_data` - Apply `SO_KEEPALIVE` and optional TCP_USER_TIMEOUT on Linux - Retry TCP/SSH connection up to `--retries` with exponential backoff - For SSH transport, detect failed `execvp` (already partially handled via exec_pipe) and retry - Protocol: no wire changes; client-side robustness only **Priority:** high **Rationale:** Without timeouts, a single hung connection can stall a sync job indefinitely. Retries are essential for automation over unreliable networks. **Acceptance criteria:** - [ ] `--timeout=30` causes a stalled receive to error out after 30 seconds - [ ] `--contimeout=10` fails fast when the server is unreachable - [ ] `--retries=3` attempts the connection three times before failing - [ ] Integration tests simulate slow/stalled server and verify timeout behavior

TapTap added the enhancement needs-triage labels 2026-07-30 18:32:18 +02:00

TapTap closed this issue

2026-07-30 19:38:28 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TapTap/FastSync#180