Indicate the datagram send state to server applications

[Masahiro Kozuka (masa-koz)]

Description

A server application never receives QUIC_CONNECTION_EVENT_DATAGRAM_STATE_CHANGED unless path MTU discovery happens to change the max send length. On a path where it does not, the application waits forever for the event and never sends a datagram, while receiving them perfectly well. docs/API.md states that the app receives this event to learn whether the peer supports receiving datagrams, so this is the code not matching the documented behaviour.

Cause

QuicDatagramOnSendStateChanged commits the new state to the QUIC_DATAGRAM unconditionally, but indicates it only when State.ExternalOwner is set:

    if (SendEnabled == Datagram->SendEnabled) {
        if (!SendEnabled || NewMaxSendLength == Datagram->MaxSendLength) {
            return;                                   // "already reported"
        }
    }

    Datagram->MaxSendLength = NewMaxSendLength;        // recorded regardless

    if (Connection->State.ExternalOwner) {             // reported only if owned
        ... QuicConnIndicateEvent(DATAGRAM_STATE_CHANGED) ...
    }

On a server the peer's transport parameters are processed before the listener hands the connection to the application. That evaluation runs unowned: it records a state that nobody can be told about, and from then on every evaluation compares equal to it and returns early. The change has been accounted for as if it were reported.

The only rescue is a later evaluation computing a different length, which in practice means MTU discovery moving Path->Mtu. Hence the same build working on one network and hanging on another.

Fix

QuicConnSetConfiguration evaluates the send state for servers, right after State.Started is set. That is the first point at which both inputs to the state are settled and there is an owner to indicate the result to — Started selects which MTU the max send length is derived from (QUIC_DPLPMTUD_MIN_MTU before it, Path->Mtu after).

That alone is not enough, because the evaluation is still swallowed whenever the recomputed values happen to equal what was recorded while unowned. They are identical when the peer uses an 8 byte connection ID over an IPv6 path with a 1280 byte MTU, which is exactly the pre-Started assumption. So whether the live state moved and whether the application's view of it is stale are now tracked separately: the early return consults the indicated state, the indicated state is updated only where an indication is actually made, and the side effects of a real state change — send shutdown, max length requeue — stay tied to the live state.

The indicated state starts out as what the application can be assumed to know already. A client opens the connection itself, so it knows the initial state; a server is handed a connection whose send state is settled before it ever sees it, so it knows nothing and assumes the conservative default of not being able to send.

Scope of the behaviour change

• Clients are unaffected. Their send state changes always have an owner to indicate to, so the indicated state never goes stale and every existing indication still fires, unchanged.
• Servers gain exactly one indication, telling the application once that it may send datagrams.
• A server whose peer does not support datagrams is still told nothing, which matches what the application already assumes. No spurious event is introduced.
• QuicDatagramValidate's !SendEnabled ⇒ MaxSendLength == 0 invariant holds on every path.
• QUIC_DATAGRAM is internal to src/core, so the two added fields are not an API or ABI change.

Testing

QuicTestDatagramNegotiation covered this path but only asserted that the server can send (GetParam(QUIC_PARAM_CONN_DATAGRAM_SEND_ENABLED)), which was true even while the application was never told. It now also asserts that the server was told: TestConnection records the count and contents of the DATAGRAM_STATE_CHANGED events indicated to it.

• Without the fix, the extended test fails on all four parameterisations (v4/v6 × datagram receive enabled/disabled).
• With the fix, the full *Datagram*:*Event*:*Mtu*:*Resumption*:*ValidateConn*:*Basic*:*Handshake* set passes: 797 tests, no failures. In particular the ordered event validators in EventTest.cpp needed no changes, confirming client behaviour is untouched.

Documentation

No documentation change. docs/API.md and docs/api/QUIC_CONNECTION_EVENT.md already describe the behaviour this change implements.