Issue with streams throughput fairness #467
Comments
|
If all the streams are the same priority, they should be sending in round-robin fashion: each "tick," the next stream is picked. If that does not happen, it's likely a bug. |
|
I agree with you, that why I think it's a bug. |
This is a typical log of my problem, there are many streams that need to write, but only stream 24 writes successfully. |
|
Nobody can help me ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I work on a new network layer for our products based on lsquic and libuv. In our product each thread use its own quic stream, so there is one connection with N quic stream. I only use the quic layer, I don't use HTTP3.
My problem is pretty simple, if I write lot of data on multiple streams, only one stream has access to the throughput, the others wait that it finished. All streams have the same priority.
I analyse the source code of lsquic but I don't know how to fix.
lsquic_stream.c:2442
there is a code that puts the stream at the end of the list, this part works.
lsquic_hpi.c:313
inside calc_next_prio_and_incr my hpi_set[0] is always equal to [4,0] with stream priority set to 255
Values are always same, prio=2 and incr=0 so I go inside next_nonincr.
lsquic_hpi.c:275
Inside next_nonincr, I go
At the end, lsquic use the method heapify_min_heap that ignore the list order, but search for the smallest stream id.
my call stack:
I tested changing the priority of the stream to 4, 5 before realizing that the order is reversed when it's not an HTTP connection, so I tried with 254 and 255, but it didn't change anything.
I don't know if I use wrong the library or if it's a bug.
Of course i'm available for more precision.
Otherwise it's a great library, thanks to you.
Thanks in advance for the help.
The text was updated successfully, but these errors were encountered: