Skip to content

Add configurable so_linger parameter for TCP and TLS links#1

Draft
Copilot wants to merge 2 commits into
masterfrom
copilot/add-so-linger-parameter
Draft

Add configurable so_linger parameter for TCP and TLS links#1
Copilot wants to merge 2 commits into
masterfrom
copilot/add-so-linger-parameter

Conversation

Copilot AI commented Mar 4, 2026

Copy link
Copy Markdown

The TCP/TLS linger timeout was hardcoded to 10 seconds with no way to configure it per-session or per-locator. This adds so_linger as a first-class session/endpoint config option, consistent with so_rcvbuf/so_sndbuf patterns.

Changes

Config schema (zenoh-config)

  • Added TcpConf { so_linger: Option<i32> } under transport.link.tcp
  • Added so_linger: Option<i32> to existing TLSConf

TCP link (zenoh-link-tcp)

  • Added TCP_SO_LINGER endpoint config key constant
  • Added TcpConfigurator implementing ConfigurationInspector<Config> — translates session-level so_linger into endpoint config (parallel to TlsConfigurator)
  • LinkUnicastTcp::new() now takes linger: Option<Duration>; get_so_linger() reads from endpoint config, falling back to TCP_LINGER_TIMEOUT
  • accept_task receives linger value captured from the listener endpoint

TLS link (zenoh-link-tls)

  • Same pattern: TLS_SO_LINGER constant, TlsConfigurator updated to emit it, LinkUnicastTls::new() and accept_task updated accordingly

Link orchestration (zenoh-link)

  • Registered TcpConfigurator in LinkConfigurator::configurations() so TCP session config propagates to endpoint config at session open time

Docs

  • Updated DEFAULT_CONFIG.json5 with commented-out so_linger entries in tcp and tls sections

Usage

Session config:

{
  transport: { link: { tcp: { so_linger: 5 } } }
}

Endpoint locator (overrides session config):

tcp/127.0.0.1:7447#so_linger=5

A negative value (e.g. -1) disables SO_LINGER. Unset defaults to 10 s (existing TCP_LINGER_TIMEOUT).

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • 224.0.0.1
    • Triggering command: REDACTED, pid is -1 (packet block)
  • 224.0.0.224
    • Triggering command: REDACTED, pid is -1 (packet block)

If you need me to access, download, or install something from one of these locations, you can either:


🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

Co-authored-by: juanjole <16036394+juanjole@users.noreply.github.com>
Copilot AI changed the title [WIP] Include so_linger parameter in session configuration Add configurable so_linger parameter for TCP and TLS links Mar 4, 2026
Copilot AI pushed a commit that referenced this pull request Apr 5, 2026
Access to `pending_queries` is synchronized using
`TablesLock::queries_lock`, which is properly acquired/release in `route_send_response`.

However, the `Query` object obtained from `pending_queries` is a
**borrow** and not an owned value. Thus, the reference may be
invalidated as soon as the lock is dropped.

I have observed this scenario in a setup with heavy query traffic at
startup where the Zenoh process was getting a SIGSEGV from Darwin at
the `observe_payload` call—here's a backtrace of the access violation
from LLDB:

```
* thread eclipse-zenoh#16, name = 'rx-4', stop reason = EXC_BAD_ACCESS (code=1, address=0x76)
  * frame #0: 0x0000000101947014 nuze-regions`_$LT$alloc..sync..Arc$LT$T$C$A$GT$$u20$as$u20$core..ops..deref..Deref$GT$::deref::hd81390341cb93fce [inlined] core::ptr::non_null::NonNull$LT$T$GT$::as_ref::h7dcbbace637a2b36 at non_null.rs:444:20
    frame #1: 0x0000000101947014 nuze-regions`_$LT$alloc..sync..Arc$LT$T$C$A$GT$$u20$as$u20$core..ops..deref..Deref$GT$::deref::hd81390341cb93fce [inlined] alloc::sync::Arc$LT$T$C$A$GT$::inner::h941100592a53d53d(self=0x0000000000000076) at sync.rs:1917:27
    frame #2: 0x0000000101947014 nuze-regions`_$LT$alloc..sync..Arc$LT$T$C$A$GT$$u20$as$u20$core..ops..deref..Deref$GT$::deref::hd81390341cb93fce(self=0x0000000000000076) at sync.rs:2232:15
    frame eclipse-zenoh#3: 0x0000000101caf0f0 nuze-regions`zenoh::net::routing::dispatcher::queries::route_send_response::h20ad9fa77f496f10(tables_ref=0x000060000345ae50, face=0x0000000171ca6d38, msg=0x0000000171ca93a0) at queries.rs:694:75
    frame eclipse-zenoh#4: 0x0000000101b2e40c nuze-regions`_$LT$zenoh..net..routing..dispatcher..face..Face$u20$as$u20$zenoh..net..primitives..Primitives$GT$::send_response::_$u7b$$u7b$closure$u7d$$u7d$::hf479d691a5485f46 at face.rs:535:9
    frame eclipse-zenoh#5: 0x0000000101b4c354 nuze-regions`_$LT$zenoh..net..routing..dispatcher..face..Face$u20$as$u20$zenoh..net..primitives..Primitives$GT$::send_response::hf3bb4f9b453622c3(self=0x000060000345ae50, msg=0x0000000171ca93a0) at face.rs:533:5
    frame eclipse-zenoh#6: 0x0000000101948b6c nuze-regions`_$LT$zenoh..net..primitives..demux..DeMux$u20$as$u20$zenoh_transport..TransportPeerEventHandler$GT$::handle_message::h1e42d16c7564472c(self=0x000060000345ae50, msg=(body = zenoh_protocol::network::NetworkBodyMut @ 0x0000000171ca8c70, reliability = Reliable)) at demux.rs:164:54
    frame eclipse-zenoh#7: 0x0000000101accdb0 nuze-regions`_$LT$zenoh..net..runtime..RuntimeSession$u20$as$u20$zenoh_transport..TransportPeerEventHandler$GT$::handle_message::h1eca52cad2cb3c31(self=0x0000600000f4f890, msg=(body = zenoh_protocol::network::NetworkBodyMut @ 0x0000000171ca8c70, reliability = Reliable)) at mod.rs:959:27
    frame eclipse-zenoh#8: 0x0000000101f6d2f8 nuze-regions`zenoh_transport::unicast::universal::rx::_$LT$impl$u20$zenoh_transport..unicast..universal..transport..TransportUnicastUniversal$GT$::trigger_callback::h0bba4e996a955f0a(self=0x000000012f0257a8, callback=&dyn zenoh_transport::TransportPeerEventHandler @ 0x0000000171ca8c98, msg=(body = zenoh_protocol::network::NetworkBodyMut @ 0x0000000171ca9510, reliability = Reliable), stats=0x000000012f025840) at rx.rs:64:18
    frame eclipse-zenoh#9: 0x0000000101f68458 nuze-regions`zenoh_transport::unicast::universal::rx::_$LT$impl$u20$zenoh_transport..unicast..universal..transport..TransportUnicastUniversal$GT$::handle_frame::h04ce3d6c841b89cb(self=0x000000012f0257a8, frame=FrameReader<zenoh_buffers::zslice::ZSlice> @ 0x0000000171caa0f0, stats=0x000000012f025840) at rx.rs:114:22
    frame eclipse-zenoh#10: 0x0000000101f694bc nuze-regions`zenoh_transport::unicast::universal::rx::_$LT$impl$u20$zenoh_transport..unicast..universal..transport..TransportUnicastUniversal$GT$::read_messages::hf2e89247bc1e5c0c(self=0x000000012f0257a8, batch=RBatch @ 0x0000000171cabd30, link=0x000000012f025860, stats=0x000000012f025840) at rx.rs:250:22
    frame eclipse-zenoh#11: 0x0000000101ffac88 nuze-regions`zenoh_transport::unicast::universal::link::rx_task::_$u7b$$u7b$closure$u7d$$u7d$::h9cd337938148db2d at link.rs:329:27
    frame eclipse-zenoh#12: 0x0000000101ff82cc nuze-regions`zenoh_transport::unicast::universal::link::TransportLinkUnicastUniversal::start_rx::_$u7b$$u7b$closure$u7d$$u7d$::hafdf078013c50ca0 at link.rs:174:14
    frame eclipse-zenoh#13: 0x000000010202fe8c nuze-regions`_$LT$tokio_util..task..task_tracker..TrackedFuture$LT$F$GT$$u20$as$u20$core..future..future..Future$GT$::poll::hc8bb990297786392(self=Pin<&mut tokio_util::task::task_tracker::TrackedFuture<zenoh_transport::unicast::universal::link::{impl#0}::start_rx::{async_block_env#0}>> @ 0x0000000171cad110, cx=0x0000000171cad280) at task_tracker.rs:680:31
```

(Tokio frames have been omitted).

This patch maintains a valid source face object by cloning its `Arc`
reference; this was sufficient to solve the SIGSEGV I observed.
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.

2 participants