Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
dgram: initial support for DATAGRAM extension
With this change, we introduce support for the DATAGRAM frame extension specified in draft-ietf-quic-datagram-01 and draft-schinazi-quic-h3-datagram-04. Several API methods have been added to the quiche transport library: * `enable_dgram()` enables the optional QUIC extension for a connection and controls internal queue sizes (see below). * `dgram_max_writable_len()` returns the size of the largest DATAGRAM frame payload that can be sent on the connection. * `dgram_send()` buffers the provided payload data in quiche, a subsequent call to `send()` constructs a DATAGRAM frame and QUIC packet. * `dgram_purge_outgoing()` purges buffered payloads matching a predicate. * `dgram_recv()` extracts payload data buffered in quiche from a prior call to `recv()`. Internally, a send and receive queue are added to quiche for the purposes of buffering the payload of DATAGRAM frames. By their specification, these frames are not flow controlled by QUIC but because of quiche's API design we benefit some ability to enqueue/dequeue application data independent from the packetization and network loop. The size of queues is configurable in order for applications to tailor things to their needs. Several API methods have been added or updated to the quiche HTTP/3 library, which internally builds on the transport library: * `dgram_max_writable_len()` returns the size of the largest DATAGRAM frame payload that can be sent on the connection. * `dgram_send()` buffers the payload for a flow ID. * `poll()` processes received DATAGRAMs and generates a `quiche::h3::Event::Datagram` if there is something to read. * `dgram_recv()` extracts payload data buffered in quiche. Previously, quiche-client and quiche-server supported HTTP/0.9, HTTP/3 or both for any given QUIC connection. During TLS handshake, ALPN would select one of these and then the applications would create HttpConn objects to handle request/response. Http09Conn simply invokes quiche transport APIs directly. Http3Conn invokes quiche transport and H3 APIs. With DATAGRAM there are many more permutations. Rather than boil the ocean, this commit introduces support for two modes, with the following CLI parameters that control how datagrams are used: ``` --dgram-proto PROTO DATAGRAM application protocol to use. --dgram-count COUNT Number of DATAGRAMs to send. --dgram-data DATA Data to send for certain types of DATAGRAM application protocol. ``` Valid values for `dgram-proto` are `siduck` and `oneway`. `siduck` works according to the I-D: the endpoints advertise the ALPN siduck, siduck-00 and if negotiated, send dgram_count number of DATAGRAM frames. The client by default sends quack, which can be overridden by the dgram-data parameter. The server simply attempts to respond to every received DATAGRAM with ${value-ack}; it ignores dgram-count and dgram-data. The client counts sent quacks and received quack acks and reports this. No HTTP requests or responses are made in this mode. `oneway` layers on top of HTTP/3. Endpoints unilaterally send dgram-count amount of HTTP/3 DATAGRAMS to each other and no accounting is done. Clients send on flow ID 0, server on flow ID 1. By default the client sends quack, the server sends brrr. Meanwhile, the apps send requests/responses in accordance with all existing CLI parameters. Fixes #430, #573. Co-authored-by: Marco Mastropaolo <[email protected]> (@xanathar)
- Loading branch information