Skip to content

feat: add non-blocking handshakes and tunnel health monitoring (#13)#21

Open
rafabd1 wants to merge 1 commit intomainfrom
feature/issue-13-accept-loop-resilience
Open

feat: add non-blocking handshakes and tunnel health monitoring (#13)#21
rafabd1 wants to merge 1 commit intomainfrom
feature/issue-13-accept-loop-resilience

Conversation

@rafabd1
Copy link
Owner

@rafabd1 rafabd1 commented Mar 14, 2026

Feature: Add non-blocking handshakes and tunnel health monitoring (#13)

Closes #13

Problem

The accept_loop has several resilience issues:

  1. Blocking handshakes: Each incoming handshake blocks the accept loop, preventing subsequent connection attempts from being processed. If multiple peers connect simultaneously, only one handshake proceeds at a time.

  2. No timeouts: Incoming handshakes can hang indefinitely if the peer becomes unresponsive during the handshake, leaving the connection in a zombie state.

  3. No tunnel health monitoring: There's no way to detect when the I2P tunnel becomes degraded or unresponsive. Users receive no feedback about tunnel status.

  4. No status feedback: Users have no visibility into whether the tunnel is healthy or degraded, making troubleshooting difficult.

These issues are particularly problematic on I2P, where network conditions can be unstable and tunnels often degrade temporarily.

Solution

Implement non-blocking handshakes with tunnel health monitoring:

  1. Non-blocking handshakes:

    • Spawn each handshake in a separate tokio task
    • Accept loop continues to process new connections while handshakes run concurrently
    • Prevents multiple connection attempts from queuing indefinitely
  2. Handshake timeouts:

    • 60s timeout for all incoming handshakes
    • Emits connection_error event on timeout
    • Prevents zombie connections from hanging indefinitely
  3. Tunnel health monitoring:

    • Background tunnel_health_monitor task runs in parallel with accept_loop
    • Checks SAM connectivity every 30 seconds
    • Quick health check via SAM HELLO command (non-invasive)
  4. Health status events:

    • tunnel_healthy: Emitted when tunnel is responsive
    • tunnel_degraded: Emitted when tunnel is unresponsive
    • Frontend can display status indicators to users

Implementation details

  • Health monitor is spawned in a separate task when accept_loop starts
  • Both tasks exit gracefully when the session is replaced or dropped
  • Health checks use simple SAM HELLO to verify connectivity
  • Timeout uses tokio::time::timeout for clean cancellation
  • All operations are non-blocking and asynchronous

Benefits

  • Accept loop remains responsive even during slow handshakes
  • Multiple connection attempts can be processed concurrently
  • Users receive feedback about tunnel health status
  • Degraded tunnels are detected quickly (within 30s)
  • No zombie connections from hanging handshakes

- Spawn handshakes in separate tasks to avoid blocking accept loop
- Add 60s timeout for incoming handshakes
- Emit connection_error events on handshake timeout
- Add tunnel_health_monitor task that checks SAM connectivity every 30s
- Emit tunnel_healthy and tunnel_degraded events for status updates
- Quick health check via SAM HELLO to verify tunnel responsiveness

This implements issue #13 to improve resilience of accept_loop. Handshakes no longer
block the accept loop, preventing multiple connection attempts from queuing indefinitely.
Users receive feedback about tunnel health status, and the app can detect when
the I2P tunnel becomes degraded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

accept_loop resilience: non-blocking handshakes and tunnel health monitoring

1 participant