Daiki AMINAKA
Daiki AMINAKA
RecvBuffer->ReadLength seems to have synchronization issue. Especially after resizing chunk
This guy does bad. Not necessarily the cap split the draining range. Or simply split ranges maybe not indicated to an app. https://github.com/microsoft/msquic/blob/a1f23396c60ca89b3641cc403eda2364de84273e/src/core/recv_buffer.c#L926
Some data broken!
Broken data is indicated when - BufferCount >= 2 - The number of Range >= 2
data corrupts where gapped ranges are merged e.g. ranges: [0 - x] [x+y - N] data[x+y] is corrupted when the gapped frame is arrived and merges the ranges
Where to handle remaining ReadPendingLength. App? api.c? stream_recv.c? recv_buff.c?
ready to go
> @ami-GS can you update the docs too? I review the code and it looks good to me. But since it's my PR I can't approve. You will have to...
What does the "flow" mean in this context? It associates N sockets to M Tx queue in NIC? Then App to specify flow ID? The article loos like kernel (tcpip)...
maybe? TAPRIO qdisc is same idea as the flow, but its hard to understand whether this is applicable to our requirements