0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:16 1 xul.dll mozglue_static::panic_hook mozglue/static/rust/lib.rs:89 2 xul.dll core::ops::function::Fn::call<fn ../18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227 3 xul.dll std::panicking::rust_panic_with_hook ../18bf6b4f01a6feaf7259ba7cdae58031af1b7b39//library/std/src/panicking.rs:573 4 xul.dll std::panicking::begin_panic::{{closure}}<str*> ../18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:498 5 xul.dll std::sys_common::backtrace::__rust_end_short_backtrace<closure-0, !> ../18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:153 6 xul.dll std::panicking::begin_panic<str*> ../18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497 7 xul.dll neqo_transport::crypto::CryptoDxState::encrypt third_party/rust/neqo-transport/src/crypto.rs:552 8 xul.dll static neqo_transport::packet::PacketBuilder::build third_party/rust/neqo-transport/src/packet/mod.rs:320 9 xul.dll neqo_transport::connection::Connection::output third_party/rust/neqo-transport/src/connection/mod.rs:1408

Add optional qlog context when creating a Connection.

Pass qlog context into Connection from neqo-client. Add cmdline option to save qlog to a file.

Implement initial trace hooks for client connected start and packet received. Still a lot more to do.

Per https://tools.ietf.org/html/draft-ietf-quic-qpack-11#section-2.1.4, it seems that a header acknowledgment obviates the requirement of sending increment instructions, in certain cases. This patch makes sure that the decoder does not send increment instructions for only the potentially-blocking references from the header block which are implictly acknowledged by the header acknowledgment.

There are a bunch of problems that might be revealed by clippy::pedantic. While false positives are a risk, we can suppress individual warnings as they are analyzed.

The usage rates of these early drafts is low enough that we should remove them. They are also a tiny bit weaker as they don't do some validation checking (on connection IDs specifically).

This will need to be coordinated with Firefox, probably by removing them from there first (which is just a few lines of code).

Yes it's a bikeshed, but it seems like some things are gated on resolving this. Here's some possibilities I'll throw out there:

1. Neqo (current working name)
2. Quico
3. Minqo
4. Sable (a Mink-like creature)
5. Polecat (same as above)
6. Quickness (QUIC + NSS)
7. Morq (Mozilla-Originated Rust-based Quic)
8. Marq (Mozilla-Authored Rust-based Quic)
9. Jiffy

I'm using a custom client to connect to the neqo server. However, the handshake never completes and this is what I get on the server side :-

Event: StateChange { conn: ActiveConnectionRef { c: RefCell { value: ServerConnectionState { c: Server Connection: Closing { error: Transport(CryptoAlert(120)), frame_type: 6, msg: "CryptoAlert(120)", timeout: Instant { tv_sec: 21793, tv_nsec: 997789700 } } None, last_timer: Instant { tv_sec: 21793, tv_nsec: 997789700 } } } }, state: Closing(Transport(376)) }

Are there any obvious reasons this could be happening ? NOTE :- The client being used successfully completes handshakes with several other QUIC Implementations.

neqo-client.log.gz

handshakeloss test occasionally fails at https://github.com/mozilla/neqo/blob/141c232d1227001fb53254b84893b071719485d2/neqo-client/src/main.rs#L719, because connecting times out

from https://github.com/mozilla/neqo/pull/591#issuecomment-622251047

We should also look to reducing our timer granularity constant. It's currently 20ms, which is far too high.

In light of use cases like #261, it seems like a good idea to create/expose a DataBlocked event (a parallel of a DataWritable event) when a send stream becomes blocked because of a lack of credits.

This should make CI builds a LOT faster.

Unfortunately, I have been unable to test that this works because dockerhub is acting strangely and I'm unwilling to give it the permissions that it thinks it needs.

The resulting image is 1.7G, which is hugely overweight. For reference, NSS builds use an image that is half that size. I wanted to keep the ability to track NSS and NSPR versions, and about 300M of that extra is in the NSS checkout, a debug build of NSS and NSPR, and other intermediate files.

I thought that NSS was the main contributor to the bloat here, but it seems like installing rust is the main contributor. Installing the minimal set of things we rely on bumps the image from 561M to 1.42G. That probably bears further investigation.

Originally thinking that NSS was the reason for the bloat, I learned something interesting about mercurial. If you remove a directory, it will happily update even if there are changes to that directory. That allowed me to remove some of the larger directories from NSS. That's worth a couple of hundred meg.

As a bonus, I've disabled building of tests for NSS, which - in addition to saving a lot of space - drives the compilation time down a lot. That applies always, so you should see that benefit elsewhere.

According to spec, the HTTP/3 datagram format is:

HTTP/3 Datagram {
     Quarter Stream ID (i),
     HTTP Datagram Payload (..),
   }

When sending a datagram, we did divide the stream id by 4, but we didn't multiply it by 4 when receiving a datagram.

I encountered this error when building gecko with v0.6.2.

 0:16.07    Compiling neqo_glue v0.1.0 (/Users/changkershaw/work/gecko/netwerk/socket/neqo_glue)
 0:16.17 error[E0603]: module `features` is private
 0:16.17    --> netwerk/socket/neqo_glue/src/lib.rs:11:5
 0:16.17     |
 0:16.17 11  |     features::extended_connect::SessionCloseReason, Error as Http3Error, Http3Client,
 0:16.17     |     ^^^^^^^^ private module
 0:16.17     |
 0:16.17 note: the module `features` is defined here
 0:16.17    --> /Users/changkershaw/work/neqo/neqo/neqo-http3/src/lib.rs:146:1
 0:16.17     |
 0:16.17 146 | mod features;
 0:16.17     | ^^^^^^^^^^^^^
 0:16.21 For more information about this error, try `rustc --explain E0603`.
 0:16.21 error: could not compile `neqo_glue` due to previous error

We currently support the draft version codepoints. Final values have been assigned for QUICv2 and I expect IANA to make a new assignment for the version negotiation draft soon. (The -13 draft is still on the codepoint we have in our code.)

We should make the change to both sets of codepoints concurrently. There is a possible interop failure if we deploy one change without the other.

When https://phabricator.services.mozilla.com/D161806 lands, we should enable greasing.

This means either tolerating a failure to set the option or bumping the NSS version requirement (and waiting for an NSS release). I might lean toward the former for the moment to avoid a pipeline stall.

Related Issue https://github.com/mozilla/neqo/issues/1367

Changes

• check if the session ID is a valid client-initiated stream id.
• check if the session ID is a valid bidirectional stream id.
• check if the session ID is a allowed value.