Tracking Issue for TCP_QUICKACK support on Linux

[berendjan]

Feature gate: #![feature(tcp_quickack)]

This is a tracking issue for linux specific socket option TCP_QUICKACK

from linux man page TCP: "Enable quickack mode if set or disable quickack mode if cleared. In quickack mode, acks are sent immediately, rather than delayed if needed in accordance to normal TCP operation. This flag is not permanent, it only enables a switch to or from quickack mode. Subsequent operation of the TCP protocol will once again enter/leave quickack mode depending on internal protocol processing and factors such as delayed ack timeouts occurring and data transfer. This option should not be used in code intended to be portable."

Public API

// std::os::linux::net

// sealed trait, implemented for std::net::TcpStream
pub trait TcpStreamExt: Sealed{
  fn quickack(&self) -> io::Result<bool>;
  fn set_quickack(&self, quickack: bool) -> io::Result<()>;
}

Steps / History

• [x] Implementation:
• [ ] Final comment period (FCP)
• [ ] Stabilization PR

Unresolved Questions

Zulip Discussion Windows .NET Discussion

Seems the windows API is significantly different from the Linux one to warrant a Linux specific trait.

[jmillikin]

FYI: The same modules are also being touched as part of the work on supporting abstract socket addresses -- see https://github.com/rust-lang/rust/issues/85410 and https://github.com/rust-lang/rust/pull/101967 for details.

I tried to keep the code intact (merely relocated), so hopefully there won't be any major conflicts.

[devnexen]

The following PR proposes to stabilise the tcp_quickack feature, being present since 2yrs+ now.

• With the following examples.
• With the following unit tests.