quic
Here are 176 public repositories matching this topic...
-
Updated
May 1, 2021 - Go
-
Updated
Apr 30, 2021 - Rust
-
Updated
May 1, 2021 - Go
-
Updated
Apr 30, 2021
Tokio's automatic cooperative task yielding feature can cause abruptly prevent a task from making further progress. A very busy connection driver might as a result end up failing to fairly serve transmits or timeouts, resulting in bad behavior (e.g. spurious timeouts or congestion window reduction) under heavy load.
Ideally tokio will expose some too
-
Updated
Mar 13, 2021 - Dockerfile
file echo_client.c, line:121 st_h->read_stdin_ev = event_new(prog_eb(st_h->client_ctx->prog),
STDIN_FILENO, EV_READ, read_stdin, st_h);
-
Updated
Apr 21, 2021 - C
-
Updated
Apr 19, 2021 - C++
-
Updated
Jan 2, 2021 - Python
-
Updated
Jan 6, 2021 - Vue
-
Updated
Mar 30, 2021 - TypeScript
-
Updated
Apr 30, 2021 - Go
I've changed my local version to:
public QuicStreamContext CreateStream(ulong streamId = 1, StreamType streamType = StreamType.ClientBidirectional);
in order to keep the compatibility.
-
Updated
May 1, 2021 - Go
-
Updated
Mar 8, 2020 - Go
Improve this page
Add a description, image, and links to the quic topic page so that developers can more easily learn about it.
Add this topic to your repo
To associate your repository with the quic topic, visit your repo's landing page and select "manage topics."
Describe the feature you'd like supported
Currently,
secnetperfserver side immediately responds to incoming stream data requests from the peer (inline). This does a great job of measuring the best possible case scenario, and gives us an idea of the upper bounds of maximum achievable performance. The problem though, is that it doesn't practically mimic a real application's behavior. Perha