-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Problem
When using TcpTls (or plain Tcp) under network conditions with packet loss, TCP's default retransmission behavior causes unbounded delivery delays. The default TCP_RETRIES2 (15 retries) means TCP will keep retransmitting for up to ~13-30 minutes before giving up, while the connection appears healthy from the application's perspective.
Currently, the only socket option set is TCP_NODELAY (in both tcp/mod.rs and tcp_tls/mod.rs connect() and poll_accept()). There's no way for consumers to configure retransmission behavior.
This is problematic for applications that implement their own reliability/recovery layer on top of msg-rs - TCP's silent retransmissions become redundant and introduce unbounded latency that the application can't control or detect.
Proposed solution
Add socket-level configuration to the Tcp and TcpTls client/server configs. At minimum:
TCP_USER_TIMEOUT(Linux) - max time (ms) unacknowledged data can remain before TCP aborts the connection. This is the most impactful option for bounding retransmission delays.
These would be applied in connect() and poll_accept() right alongside the existing set_nodelay(true) call:
let stream = TcpStream::connect(addr).await?;
stream.set_nodelay(true)?;
#[cfg(target_os = "linux")]
if let Some(timeout) = config.user_timeout {
// setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, timeout_ms)
}Nice-to-haves (follow-up)
SO_KEEPALIVE+TCP_KEEPIDLE/TCP_KEEPINTVLfor faster dead connection detection- Exposing these through the
Controlchannel for runtime tuning (note:SubDriverdoesn't currently wire upcontrol_rx, so this would also need work in msg-socket)