mcmanus / mozquic Goto Github PK

either totally on its own, or create a pollable FD to be called back.

client and server paths are almost the same, they can be combined

We have a whole bunch of error states that should send connection errors but instead just report errors to the application.. this is mostly because

a] we still don't have a plan for what to do when you can't make a protected packet for close (ignore this category for until we do)

b]we hadn't written the close generation time at the time the error paths were written

todo: quick pass through transport and flag cases where we have implemented the feature and MUST send a close - do so, or file individual bugs

right now when a connection uses HRR (server stateless retry) the server app will receive a EVENT_NEW_CONNECTON followed by a EVENT_ERROR.. and then later on when the second client hello comes in a new EVENT_NEW_CONNECTION (and probably EVENT_CONNECTED when the cookies is verified.

This is a rather horrible experience and version negotiation (the other thing that can add a rtt during handshake) doesn't do it.. but all the tls is processed asynchronously and its really hard to not have a connection-callback around for any error processing during that state.. nonetheless - we can do better.

the quic design assumes close is more like RST than anything else and that a graceful shutdown of existing streams happens first.

the mozquic client api should have a method to close() all the open streams and at least wait for any unacked data before sending CLOSE on the connection

Some kind of level triggered mode would help callers do the right thing.

We're mostly there on the qdrive branch, but the request format isn't exactly HTTP 0.9

implement receipt of it at least

oldConnectIDs list could be its first user.

some kind of delack, and some kind of coalescing of ranges better than what happens now (which only works when they are received contiguously), and perhaps not sending out the acks unless there has been some addition to it or some timer has gone off

flow control is rather crude in how it issues credits

some text changed
quicwg/base-drafts#750

both send and recv

right now the unacked data list involves transmitted frames, so the data has to be copied into frame-sized chunks. It would be better to keep a reference counted blob of data and have the trasmitted frame list just hold a reference, ptr, and len into the blob.

This will solve the problem we have of n^2 copying of really big send()s right now

max_data and max_stream_id

the config struct contains some stuff that is really only for testing - so we should have a trendy experimental api that will fail soft if not running in "experimental" mode (which will allow production apps to test safely)

right now its probably not threadsafe at all.. we can do better. relatedly all recv is done by 1 fd on one thread, but can probably be spread out

after receipt of server_cleartext dont allow version negotiation

Public/Stateless Reset (generate where appropriate; validate & process correctly)

https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.7.8

right now we always use 1200.. it would be ok to do some pings (maybe at ~1460 and ~1350) right after handshake to verify a larger mtu

its used in checkpeer, shutdown, and normal protected packets

levels, categories, timestamps, the usual

Session Tickets can be sent by the server after completion of the handshake on stream 0 using protected packets.

Packets without a session will be dropped - but its possible some of the handshake is just reordered. we should hold onto them for a brief period of time.

generating version negotiation has new rules.. among them is only do it on long form packets at least 1200 bytes long

load an 09 page

The timestamp section lists packet receipt timestamps ordered by timestamp.

mozquic sorts it according to packet number.

everything assumes keypair 0

This is already done on the TLS client (e.g. gecko) side. It might be interesting to have a sample openssl application.

just like acks, we need to rexmit flow control data but not the packets. (i.e. if you send 1, 3, 5 its only 5 that needs to be resent if not acked)

quicwg/base-drafts#806

max_stream_data and stream_blocked

Right now, when data moves past the flow control gate it is because all the streams are polled for any data they want to promote. That needs to be an event based algorithm for efficiency.

From the handshake..

want to remember this.. its really only a theoretical problem If the packet number for sending reaches 2^64 - 1, the sender MUST close the connection by sending a CONNECTION_CLOSE frame with the error code QUIC_SEQUENCE_NUMBER_LIMIT_REACHED (connection termination is described in Section 7.7.)

https://nss-review.dev.mozaws.net/D423

but pure acks do not. (padding is a bug right now - base draft #838)

because fixed timers aren't good enough

that's really not cool.

right now the library only allows manual xon/xoff signals to control flow control (and even there, its global). A mode that applied backpressure based on how much data was buffered would be good.