Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for TCP_QUICKACK support on Linux #96256

Open
1 of 3 tasks
berendjan opened this issue Apr 20, 2022 · 2 comments
Open
1 of 3 tasks

Tracking Issue for TCP_QUICKACK support on Linux #96256

berendjan opened this issue Apr 20, 2022 · 2 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@berendjan
Copy link

berendjan commented Apr 20, 2022

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

  • 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.

@berendjan berendjan added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 20, 2022
@berendjan berendjan changed the title Tracking Issue for XXX Tracking Issue for TCP_QUICKACK support on Linux Apr 20, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 7, 2022
Add setter and getter for TCP_QUICKACK on TcpStream for Linux

Reference issue rust-lang#96256

Setting TCP_QUICKACK on TcpStream for Linux
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 7, 2022
Add setter and getter for TCP_QUICKACK on TcpStream for Linux

Reference issue rust-lang#96256

Setting TCP_QUICKACK on TcpStream for Linux
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 28, 2022
Add setter and getter for TCP_QUICKACK on TcpStream for Linux

Reference issue rust-lang#96256

Setting TCP_QUICKACK on TcpStream for Linux
@jmillikin
Copy link
Contributor

FYI: The same modules are also being touched as part of the work on supporting abstract socket addresses -- see #85410 and #101967 for details.

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

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 14, 2022
…dr, r=joshtriplett

Move `unix_socket_abstract` feature API to `SocketAddrExt`.

The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered.

This PR makes four changes:
1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there.
2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change).
3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer.
4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly.

Issues:
1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 14, 2022
…dr, r=joshtriplett

Move `unix_socket_abstract` feature API to `SocketAddrExt`.

The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered.

This PR makes four changes:
1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there.
2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change).
3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer.
4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly.

Issues:
1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 14, 2022
…dr, r=joshtriplett

Move `unix_socket_abstract` feature API to `SocketAddrExt`.

The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered.

This PR makes four changes:
1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there.
2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change).
3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer.
4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly.

Issues:
1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
thomcc pushed a commit to tcdi/postgrestd that referenced this issue Feb 10, 2023
…htriplett

Move `unix_socket_abstract` feature API to `SocketAddrExt`.

The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang/rust#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered.

This PR makes four changes:
1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang/rust#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there.
2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change).
3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer.
4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly.

Issues:
1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
@devnexen
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants