webrtc: track number of bytes sent / received by all substreams#3162
webrtc: track number of bytes sent / received by all substreams#3162melekes wants to merge 10 commits into
Conversation
|
Just logging without the headers would have the advantage of being a generic solution, as it could be plugged on top of any |
| })); | ||
| } | ||
|
|
||
| /// Fetches the current bandwidth (for all connections). Counters are reset after each call. |
There was a problem hiding this comment.
I know this is not perfect from API design, but it's the trade-off. You can browse the commit history.
| } | ||
|
|
||
| // #[cfg(all(feature = "uds", feature = "async-std"))] | ||
| // impl WithBandwidthSinks for async_std::os::unix::net::UnixStream { |
There was a problem hiding this comment.
not sure what to do with transports who don't have their own connection type. is it okay to import async_std/tokio here? or I should reexport these types?
| Transport, | ||
| }; | ||
| use rw_stream_sink::RwStreamSink; | ||
| pub use rw_stream_sink::RwStreamSink; |
There was a problem hiding this comment.
is it okay to reexport to avoid importing rw_stream_sink in src/bandwidth.rs?
There was a problem hiding this comment.
I'd suggest make a type alias for the stream. That is why I did for TCP.
Thanks for commenting! I thought I had read a comment from you somewhere that you'd prefer if we measured as far down the stack as possible. I'd very much be in favor of a generic solution instead of what we have here at the moment. Ideally, maybe even segregated by protocol, e.g. However, we can only do that if the trade-offs involved are acceptable for people. |
| Transport, | ||
| }; | ||
| use rw_stream_sink::RwStreamSink; | ||
| pub use rw_stream_sink::RwStreamSink; |
There was a problem hiding this comment.
I'd suggest make a type alias for the stream. That is why I did for TCP.
I was under the same impression as well.
Same. @mxinden proposed counting only the goodput here: #3157 (comment) |
|
Let's continue the discussion here |
|
Replaced by #3180 |
3 participants
Continuation of #3161