Tracking Issue for `tcp_linger`

[ibraheemdev]

Feature gate: #![feature(tcp_linger)]

This is a tracking issue for the TcpStream::linger and TcpStream::set_linger methods that get/set the SO_LINGER option on the socket. Behavior works as expected on both Unix and Windows.

Public API

impl TcpStream {
    pub fn set_linger(&self, linger: Option<Duration>) -> io::Result<()>;
    pub fn linger(&self) -> io::Result<Option<Duration>>;
}

Steps / History

• Implementation: Add TcpStream::set_linger and TcpStream::linger #88495
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should enabling lingering and setting the duration be split out into two operations?

[ibraheemdev]

Similar to the TCP keepalive, there are actually two operations here. Enabling lingering, and setting the duration. Right now we use an option for both, but we might want to separate these out. For reference, C# has the following API:

public class LingerOption {
   public bool Enabled { get; set; }
   public int LingerTime { get; set; }
}

public class TcpClient {
    // ...
    public LingerOption? LingerState { get; set; }
}

[anisse]

Similar to the TCP keepalive, there are actually two operations here. Enabling lingering, and setting the duration. Right now we use an option for both, but we might want to separate these out.

At least on Linux, this wouldn't match the underlying syscall behavior. The setsockopt SO_LINGER needs a duration when linger is enabled. Otherwise what would be the default value ? Would enabling mean two syscalls ? I think the way the nightly rust api is currently designed is a better match to linux semantics.

Edit: apparently the windows implementation uses libc's setsockopt too ? So it also matches the windows semantics ?

[joboet]

I'm worried about the current handling of long Duration values. The current implementation uses a truncating cast:

rust/library/std/src/sys/net/connection/socket/unix.rs

Line 431 in 19cab6b

l_linger: linger.unwrap_or_default().as_secs() as libc::c_int,

so calling set_linger with a Duration of u32::MAX + 1 seconds will actually enable lingering with a timeout of zero seconds. This is even more likely on Cygwin where the seconds field is a u16.

Maybe the method should return an error instead if the duration is too long? Otherwise, I think we should use saturating conversion to guarantee at least some amount of lingering.

[RalfJung]

@rust-lang/libs-api this has been lingering for a while, is there anything blocking its stabilization?

Above there has been discussion of how the Duration argument should be handled. We already have set_read_timeout/set_write_timeout, so it seems to be the easiest to just follow their precedent?

@joboet

I'm worried about the current handling of long Duration values. The current implementation uses a truncating cast:

That seems not great indeed. What do set_read_timeout/set_write_timeout do?