Closed cybersoulK closed 1 year ago
i also do have maximum MTU at 1100, could that be why?
and it freezes for only one client at a time, while having clients still work normally, so less likely to be tokio::select! ?
another info: it happens both on localhost and remotely
Conclusion: after an burst of packages (10-20 packets at the same time?), the client decides to start fragmenting packages outbound, which fell below the 1100 mtu, (maybe starts fragmenting by 500 bytes), and the webrtc-unreliable crate doesn't have a way to handle fragmented packages yet
webrtc-unreliable crate doesn't have a way to handle unfragmented packages yet
I'm very confused, that's not true? Unfragmented at what layer?
webrtc-unreliable crate doesn't have a way to handle unfragmented packages yet
I'm very confused, that's not true? Unfragmented at what layer?
sorry, mean't to say fragmented, corrected the comment.
hi! having a strange bug where the connection outbound freezes for the client, but inbound still works normally
after a certain condition, not easy to replicate, usually takes 10 minutes, and a big amount of packages sent at once, like 30 packets at once by the server to the client
statistics below is after it freezes, and within 1 second interval:
client: incoming => new packets: 72, new bytes: 55033. outgoing => new packets: 18, new bytes: 755.
server: incoming => new packets: 0, new bytes: 0. outgoing => new packets: 91, new bytes: 66947.
i do have my own transport layer, and flush 300 times every second with a web worker (if there is any data), maybe that's why, and interrupts something in tokio::select?