You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, first of all thanks for all the awesome work.
I have a question regarding Tokio's TCP Listener / Stream.
I have the following setups:
Tokio TCP Stream -> Hyper Low-Level HTTP
Tokio TCP Stream -> Tokio/tls (Rustls) -> Hyper Low-Level HTTP
This allows me to analyse all incoming traffic correctly. Only thing that I cannot easily trace for analytics purposes is the options for incoming packets such as the Client's defined TTL / Window Size.
Via tools like wireshark I can easily see these values, but as I currently treat the TCP stream as a stream of bytes I do not really have access to the low-level incoming TCP packets.
How would I in my current flow (or an improvement of it) never the less have access to what values the client has chosen for these values? I would have hoped that the stream remembered the values or last known values it encountered for these, but that was wishful thinking, and of course it might anyway not be that useful to expose this anyhow.
Anyone an idea here? it's not a deal breaker FYI, as such TCP options are anyhow not that trust worthy given the TCP conns might come via load-balancers and proxies anyhow, making it not even sure if it came from actual client in first place, but I was wondering none the less anyhow...
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, first of all thanks for all the awesome work.
I have a question regarding Tokio's TCP Listener / Stream.
I have the following setups:
This allows me to analyse all incoming traffic correctly. Only thing that I cannot easily trace for analytics purposes is the options for incoming packets such as the Client's defined TTL / Window Size.
Via tools like wireshark I can easily see these values, but as I currently treat the TCP stream as a stream of bytes I do not really have access to the low-level incoming TCP packets.
How would I in my current flow (or an improvement of it) never the less have access to what values the client has chosen for these values? I would have hoped that the stream remembered the values or last known values it encountered for these, but that was wishful thinking, and of course it might anyway not be that useful to expose this anyhow.
Anyone an idea here? it's not a deal breaker FYI, as such TCP options are anyhow not that trust worthy given the TCP conns might come via load-balancers and proxies anyhow, making it not even sure if it came from actual client in first place, but I was wondering none the less anyhow...
Beta Was this translation helpful? Give feedback.
All reactions