Repository navigation
TCP_INFO support #362
Description
Activity
This would be a nice addition. I think we should use same strategy we do for Mio's event: https://github.com/tokio-rs/mio/blob/1f8cd972f7a575e097c29da1e5aa2d4b7f399d8d/src/event/event.rs. That is define a
TcpInfostruct that wraps thetcp_infoOS specific struct and define getters onTcpInfoto get the OS specific data.Thank you for thinking about my request. Merely being able to log TCP_INFO before closing a TCP stream would be an awesome improvement on what happens today. Being able to poll it frequently, would allow for a rust application to better rate limit itself. I look at these frameworks, and my mind crashes, but it is indeed, just one system call, or auxiliary data that can be pulled from a tcp request.
The way that google measurement labs does it though, is different, in that they just log the whole binary tcp_info struct as one record, and figure out how to parse it later - from the kernel, the order of the fields is garunteed to be stable, but every new linux kernel release has added more data to that struct. So despite that innate desire to provide accessor functions you appear to have, just getting that whole structure from point a to point b, somehow, is helpful.
Somewhat related, recently a rather large microservices user, realized that 80% of the data they were sending to the web server never made it to the users, they applied the TCP_NOTSENT_LOWAT option (I think, 32k) to a huge improvement in overall service time. This document might provide some insight as to who that was (it led to the apache traffic server patch)
Thank you for thinking about my request. Merely being able to log TCP_INFO before closing a TCP stream would be an awesome improvement on what happens today. Being able to poll it frequently, would allow for a rust application to better rate limit itself. I look at these frameworks, and my mind crashes, but it is indeed, just one system call, or auxiliary data that can be pulled from a tcp request.
I'm not sure if you're implying that socket2 should log anything, but we're not going to do that. We can add a nice getter and setter function to the
Sockettype though.I am interested in implementing this interface, but I have a question for which I haven't come up with a good solution: the struct
tcp_infowill have different implementations for different kernel versions, and we need to generate bindings for the header file/usr/include/linux/tcp.haccordingly. So how can we define aTcpInfostruct that wraps thetcp_infoOS specific struct and define getters onTcpInfoto get the OS specific data? (how do we handle non-presented fields intcp_infoinTcpInfowhen in older versions?)I am interested in implementing this interface, but I have a question for which I haven't come up with a good solution: the struct
tcp_infowill have different implementations for different kernel versions, and we need to generate bindings for the header file/usr/include/linux/tcp.haccordingly.I don't want to maintain a struct definition, this will have to live in the libc crate.
So how can we define a
TcpInfostruct that wraps thetcp_infoOS specific struct and define getters onTcpInfoto get the OS specific data? (how do we handle non-presented fields intcp_infoinTcpInfowhen in older versions?)For the type in socket2 we can define something like
struct TcpInfo { inner: sys::tcp_info }, wheresys::tcp_infoislibc::tcp_infofor Unix and something else for Windows (maybewindows_sys::Win32::Networking::WinSock::TCP_INFO_v1? I don't know). Similar toTcpKeepalivewe'll have the appropriate getters and setters depending on the OS, see:
Lines 401 to 552 in b39fdc6
I don't want to maintain a struct definition, this will have to live in the libc crate.
Ok, then I think this feature might be blocked since libc haven't implemented this struct libc/#1609 for linux. I will see if there is an opportunity to implement
tcp_infofor libc in the future.Reacted by Thomas de Zeeuw and Surajthe windows v2 tcp_info header is better, as it has more of the variables I (at least) care about. Thx, all for looking into it.
TCP_INFO (struct tcp_info) contains metrics for how the tcp layer is performing, and lends insight into what is otherwise a black box for most folk. Notable are base rtt, rtt, loss, retries, ecn_seen from my perceptual worrying-about-bufferbloat perspective...
Windows impl:
https://learn.microsoft.com/en-us/windows/win32/api/mstcpip/ns-mstcpip-tcp_info_v1
Apache traffic server's implementation: https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/plugins/tcpinfo.en.html
How google measurement labs uses it: https://www.measurementlab.net/tests/tcp-info/ (out of band in this case)
It would be really nice to be able to monitor this set of metrics for more applications.