microsoft/msquic

Describe the bug When MsQuic is built with QUIC_ENABLE_LOGGING=OFF, QuicConnLogOutFlowStats() still scans all live streams to collect statistics that goes nowhere. I've added an early return in QuicConnLogOutFlowStats() and it reduced latency by 90% at following SecNetPerf benchmark: ./build/repro/bin/Release/secnetperf -target:localhost -conns:1 -streams:1000 -rstream:1 -run:10s -up:512 -down:4kb -plat:1 Modified code: QUIC_INLINE void QuicConnLogOutFlowStats( _In_ const QUIC_CONNECTION* const Connection ) { // Added this branching #if defined(QUIC_EVENTS_STUB) && !defined(QUIC_EVENTS_STDOUT) // Event tracing is a no-op; avoid scanning all live streams for statistics. return; #endif if (!QuicTraceEventEnabled(ConnOutFlowStats)) { return; } QuicCongestionControlLogOutFlowStatus(&Connection->CongestionControl); uint64_t FcAvailable, SendWindow; QuicStreamSetGetFlowControlSummary( &Connection->Streams, &FcAvailable,

Describe the bug We develop IceRPC, an RPC framework with QUIC support. We naturally use .NET's System.Net.Quic, which in turn uses msquic. Our test suite establishes many short-lived QUIC connections: each test typically creates a listener on 127.0.0.1:0, connects, exchanges a little data, and closes everything. When running this suite on macOS, from time to time, a random test fails because a connection establishment timed out (took over 10 seconds), even though the same handshake completes in about a millisecond in every other run. We have not seen this failure on Linux or on Windows. We reduced the failure first to a standalone System.Net.Quic program and then to the C++ program below, which uses the msquic API directly with no .NET or IceRPC code at all. At the msquic level the failure is a transport shutdown with QUIC_STATUS_CONNECTION_IDLE (0x65) during connection establishment on loopback. Under sustained connect load (8 threads opening a listener on 127.0.0.1:0, connecting, an

Describe the feature you'd like supported I would like MsQuic to support Raw Public Keys (RPK) as defined in RFC 7250. Currently, this feature can be used with OpenSSL, SChannel doesn't support it. Motivation This is a preferred solution to use in P2P (peer-to-peer) networks like blockchain. Using X.509 certificates for such scenarios is impractical because it requires either: A centralized Certificate Authority, which contradicts the decentralized nature of P2P. Self-signed certificates, which still require additional validation logic and add unnecessary overhead to the handshake. Additional context I am developing a blockchain node in C#. Unfortunately, the blockchain core team doesn't want to use authentication using X.509 certificates, so I will have to implement RPK in MsQuic.

Describe the bug Visual Studio 2019 msQUIC 2.6.0 The VS project treats warnings as errors, and there are a few warnings that will prevent complete build unless disabled by /wd api.c : C6101 crypto_tls.c : C28020 datapath_Raw.c : C6385 datapath_Raw_xdp_win.c : C6385, C6001 storage_winuser.c: C6101 Affected OS Windows Linux macOS Other (specify below) Additional OS information Windows 10 MsQuic version 2.6.0 Steps taken to reproduce bug Using Cmake Just change QUIC_TLS_LIB to either openssl or quictls Expected behavior It should build rather than stopping on warning Actual outcome The build stops Additional details No response

Describe the feature you'd like supported Hope to support wolfSSL encryption Motivation Hope to support wolfSSL encryption Additional context No response