Feature Request: Add TCP Keep-Alive configuration options to Node settings

[AGENT3128]

Summary

When monitoring remote nodes using Monitor(target), network disconnection detection takes approximately 150 seconds due to default system TCP keep-alive settings. It would be beneficial to expose TCP keep-alive configuration at the node level.

Problem Description

I'm using Monitor(target) to track remote nodes. When a node loses network connectivity (e.g., systemctl stop network), the session termination is detected only after ~150 seconds. This delay corresponds to system-level keep-alive settings and genDefaultKeepAlivePeriod (15 seconds):

$ sysctl -a | grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

Modifying system-wide settings is not desirable in many production environments.

Proposed Solution
Add KeepAliveConfig to the node configuration options:

type KeepAliveConfig struct {
    // Enable indicates whether keep-alive probes are enabled.
    Enable bool

    // Idle is the time that the connection must be idle before
    // the first keep-alive probe is sent.
    // If zero, a default value of 15 seconds is used.
    Idle time.Duration

    // Interval is the time between keep-alive probes.
    // If zero, a default value of 15 seconds is used.
    Interval time.Duration

    // Count is the maximum number of keep-alive probes that
    // can go unanswered before dropping a connection.
    // If zero, a default value of 9 is used.
    Count int
}

This would allow per-connection keep-alive tuning using Go's net.TCPConn.SetKeepAliveConfig() (available since Go 1.24).

Use Case

• Faster detection of network failures in distributed systems
• No need to modify system-level TCP settings
• Fine-grained control over connection health monitoring

Additional Context
Go 1.24 introduced net.KeepAliveConfig which allows setting these parameters per-connection:
https://pkg.go.dev/net#KeepAliveConfig

[halturin]

Thanks, its a good feature. Was thinking about it a while ago. I'll take a look at where/how it can be integrated.

[halturin]

network disconnection detection takes approximately 150 seconds

It takes that long only if nothing is being sent between the nodes. In real life, it happens (detection) almost instantly. Am i wrong?

[AGENT3128]

You're right that graceful termination (SIGKILL/SIGTERM) is detected almost instantly - that works correctly.

However, the issue occurs specifically with network disconnection (e.g., systemctl stop network on the remote node). Here's my test scenario:

Architecture:

Actor A: Sends data to a remote actor every second
Actor B: Uses Monitor(target) to track the remote node
Comparison of two scenarios:

Scenario	Detection Time	Error Message
Graceful shutdown (SIGKILL/SIGTERM)	Instant	dial tcp IP:11144: connect: connection refused
Network disconnection (systemctl stop network)	~150 seconds	dial tcp IP:11144: i/o timeout or connect: no route to host

Observed behavior when network is disabled on the remote node:

Actor A immediately starts receiving errors (i/o timeout, no route to host)
Actor B's Monitor() detects the node loss only after ~150 seconds ((9+1) × 15sec)

15 sec = gen.DefaultKeepAlivePeriod
net.ipv4.tcp_keepalive_probes = 9

So even though there's active traffic (1 msg/sec), the Monitor() detection still relies on TCP keep-alive timeouts rather than detecting the failure from the sending path. It seems like the monitoring mechanism and message sending use separate connections or the send failures don't propagate to the monitor state.

This is why per-connection keep-alive configuration would be valuable - to reduce detection time in network failure scenarios without modifying system-wide settings.

[AGENT3128]

Off-topic question:

Is there a public release schedule or roadmap available? I'm trying to understand the release lifecycle and get a rough estimate of when v320 might be considered stable. This would help with planning adoption in production environments.

[halturin]

It seems like the monitoring mechanism and message sending use separate connections or the send failures don't propagate to the monitor state.

In Ergo, a connection is actually a pool of TCP connections. When sending a message, it picks one of the connections from the pool and writes to it. But yes, it has to be improved, for sure.

Is there a public release schedule or roadmap available?

It's internal only. But version 3.2 is scheduled for February 4.
I usually post any updates in Telegram (here’s one about the release schedule: https://t.me/ergo_services/1/1801).
Sometimes I also post on https://x.com/halturin, but not very often.

[halturin]

Worth mentioning that about a month before the release we enter a feature-freeze state.
Anyway, I usually keep the v*** branches clean and stable, so you can consider them release candidates.