Coder Social home page Coder Social logo

nodejs / quic Goto Github PK

View Code? Open in Web Editor NEW
301.0 29.0 49.0 436.6 MB

This repository is no longer active.

License: Other

JavaScript 54.77% Makefile 0.26% Shell 0.18% R 0.04% HTML 0.90% C++ 28.62% Python 12.05% C 2.55% DTrace 0.21% Roff 0.06% Batchfile 0.22% Emacs Lisp 0.08% Perl 0.06% Assembly 0.01%

quic's Introduction

Node.js

Node.js is an open-source, cross-platform, JavaScript runtime environment. It executes JavaScript code outside of a browser. For more information on using Node.js, see the Node.js Website.

The Node.js project uses an open governance model. The OpenJS Foundation provides support for the project.

This project is bound by a Code of Conduct.

Table of Contents

Support

Looking for help? Check out the instructions for getting support.

Release Types

  • Current: Under active development. Code for the Current release is in the branch for its major version number (for example, v10.x). Node.js releases a new major version every 6 months, allowing for breaking changes. This happens in April and October every year. Releases appearing each October have a support life of 8 months. Releases appearing each April convert to LTS (see below) each October.
  • LTS: Releases that receive Long-term Support, with a focus on stability and security. Every even-numbered major version will become an LTS release. LTS releases receive 12 months of Active LTS support and a further 18 months of Maintenance. LTS release lines have alphabetically-ordered codenames, beginning with v4 Argon. There are no breaking changes or feature additions, except in some special circumstances.
  • Nightly: Code from the Current branch built every 24-hours when there are changes. Use with caution.

Current and LTS releases follow Semantic Versioning. A member of the Release Team signs each Current and LTS release. For more information, see the Release README.

Download

Binaries, installers, and source tarballs are available at https://nodejs.org/en/download/.

Current and LTS Releases

https://nodejs.org/download/release/

The latest directory is an alias for the latest Current release. The latest-codename directory is an alias for the latest release from an LTS line. For example, the latest-carbon directory contains the latest Carbon (Node.js 8) release.

Nightly Releases

https://nodejs.org/download/nightly/

Each directory name and filename contains a date (in UTC) and the commit SHA at the HEAD of the release.

API Documentation

Documentation for the latest Current release is at https://nodejs.org/api/. Version-specific documentation is available in each release directory in the docs subdirectory. Version-specific documentation is also at https://nodejs.org/download/docs/.

Verifying Binaries

Download directories contain a SHASUMS256.txt file with SHA checksums for the files.

To download SHASUMS256.txt using curl:

$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt

To check that a downloaded file matches the checksum, run it through sha256sum with a command such as:

$ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -

For Current and LTS, the GPG detached signature of SHASUMS256.txt is in SHASUMS256.txt.sig. You can use it with gpg to verify the integrity of SHASUM256.txt. You will first need to import the GPG keys of individuals authorized to create releases. To import the keys:

$ gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D

See the bottom of this README for a full script to import active release keys.

Next, download the SHASUMS256.txt.sig for the release:

$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig

Then use gpg --verify SHASUMS256.txt.sig SHASUMS256.txt to verify the file's signature.

Building Node.js

See BUILDING.md for instructions on how to build Node.js from source and a list of supported platforms.

Security

For information on reporting security vulnerabilities in Node.js, see SECURITY.md.

Contributing to Node.js

Current Project Team Members

For information about the governance of the Node.js project, see GOVERNANCE.md.

TSC (Technical Steering Committee)

TSC Emeriti

Collaborators

Collaborator Emeriti

Collaborators follow the Collaborator Guide in maintaining the Node.js project.

Release Keys

Primary GPG keys for Node.js Releasers (some Releasers sign with subkeys):

To import the full set of trusted release keys:

gpg --keyserver pool.sks-keyservers.net --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
gpg --keyserver pool.sks-keyservers.net --recv-keys 94AE36675C464D64BAFA68DD7434390BDBE9B9C5
gpg --keyserver pool.sks-keyservers.net --recv-keys 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1
gpg --keyserver pool.sks-keyservers.net --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600
gpg --keyserver pool.sks-keyservers.net --recv-keys C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8
gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D
gpg --keyserver pool.sks-keyservers.net --recv-keys A48C2BEE680E841632CD4E44F07496B3EB3C1762
gpg --keyserver pool.sks-keyservers.net --recv-keys B9E2F5981AA6E0CD28160D9FF13993A75599653C

See the section above on Verifying Binaries for how to use these keys to verify a downloaded file.

Other keys used to sign some previous releases:

quic's People

Contributors

addaleax avatar apapirovski avatar bnoordhuis avatar bridgear avatar cjihrig avatar danbev avatar fishrock123 avatar indutny avatar isaacs avatar jasnell avatar joyeecheung avatar koichik avatar mhdawson avatar mscdex avatar mylesborins avatar piscisaureus avatar refack avatar ronag avatar rvagg avatar ry avatar sam-github avatar shigeki avatar targos avatar timothygu avatar tjfontaine avatar tniessen avatar tootallnate avatar trevnorris avatar trott avatar vsemozhetbyt avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

caijw emamatcyber90 jasnell nicknaso bhanditz p79n6a lpardue juanarbol gengjiawen normanjoyner oyyd addaleax palem1988 omerherera italoacasas lundibundi moontahoe ronag benhalverson peddlerlabs lingnet zys-contrib nikolasmelui alexpresss halleyassist betotto base-37 isabella232 codzart roboclam global-localhost global19 global19-atlassian-net blackshady pd4d10 ahnchan benji0522 tysonrm wangz2023 blackbird-devs benyang3028 stoneson johan511 terryjoo lww97 betterwzc tonelomb doctorcode-org

quic's Issues

TODO: Implement the HTTP/3 layer

The HTTP/3 layer will involve use of nghttp3 and an additional set of specializations for the native QuicSession/QuicClientSession/QuicServerSession/QuicStream classes. Work on this will begin in early September.

Getting Started

This repo is dedicated to working on a QUIC implementation for Node.js core. I am still getting the fundamentals pulled together so won't be landing any PRs yet, but wanted to at least get things bootstrapped.

I will be creating a quic team. Please comment here if you'd like to be included on that.

There are several prerequisites that need to be looked at before we can really get moving:

  1. Integrating ngtcp2 for all supported Node.js platforms
  2. Our version of OpenSSL needs modifications to support QUIC. We would need to float those changes as it's not clear if they can be merged upstream. It's also not yet clear if those changes would affect non-QUIC OpenSSL uses. Will be investigating. QUIC requires TLS 1.3.
  3. The existing UDPWrap needs to be modified to allow it to more easily be used directly from the native side, including writing and reading data.

Please add any additional thoughts you may have to this thread.

QuicBuffer

Ok, so the implementation is in a state where things are basically working but there is still a ton of work to do in order to get it complete. There's one major PR that I'll get landed later on today. The next big piece will be nailing down the implementation of QuicBuffer so the data flow from JS to C++ and back, with as little memcpy'ing as possible, works and is as efficient as possible. I have a few other things to work on over the next couple of days but I'll be working sporadically on the QuicBuffer implementation over the coming days and would love input on it.

The basic break down is this:

QuicSocket wraps the uv_udp_t handle and deals with sending packets. Unlike traditional UDP, QUIC includes error handling that requires packets to be re-transmitted until they are acknowledged by the peer. This means we cannot simply fire and forget a uv_buf_t and free it when the libuv callback is triggered. We have to keep the ub_buf_t around until ngtcp2 receives and processes the acknowledgement.

Data is sent at multiple places: 1) by QuicSocket itselr (e.g. version negotiation, close, errors, etc) ... 2) by QuicSession (and the QuicServerSession and QuicClientSession specializations) during TLS handshake and regular stream management, and 3) by QuicStream.

There are multiple data buffers at play. TLS handshake has it's own outgoing buffer, every QuicStream has it's own outgoing buffer. There are several places in the code where more transient buffers are used. It's fairly complicated but the bottom-line is that we cannot free buffers as soon as the libuv callback is triggered because we may need to retransmit those multiple times.

The current QuicBuffer implementation is modeled after the example code in ngtcp2, and it works reasonably well for what it does right now but it does not really do what we need it to do, particularly with regards to proper Stream API support callbacks when we can actually free data. It also depends heavily on memcpy at several places making it quite inefficient. It needs a better implementation.

It will likely be a few days before I can really dig in but I would love to open this bit up to others who may have some good ideas on how to handle the data flow here (ahem, @addaleax :-D .. since I love what you did with http2's internal data flow).

If someone wanted to start poking around with those bits, I'm happy to answer questions or help point in the right direction :-)

TODO: Update patched openssl & fixup

Within the past week or so, ngtcp2 updated to use a new version of the patched openssl library with a whole new set of APIs based on Boring (details here: openssl/openssl#8797).

These represent what will ultimately be the official openssl APIs so we need to switch. Unfortunately, the implementation appears to be based on Openssl 3 so it's going to need to be backported with floated patches until we can upgrade to a version of OpenSSL that has these built in (the PR that adds them hasn't even landed yet so .....)

The good news is once we land this, ngtcp2 provides utility APIs that greatly reduce what we need to implement and maintain within Node.js (over half of the code in node_quic_crypto.h goes away and handshake/crypto logic becomes much easier.)

I'm investigating what we need to do to port the changes.

TODO: Improve connection close reporting

When a QuicSession is closed with a received CONNECTION_CLOSE, make sure the connection close error code is transmitted out to the JavaScript side so the user can know why the connection was closed.

TODO: Refactor out handshake logic from QuicSession

One of the long standing todos I've had is to separate the TLS Handshake logic from the QuicSession for a couple of reasons:

  1. We won't know the alpn identifier until the handshake completes, so we won't really know if we're creating a HTTP3 session or a generic QUIC session

  2. Separating out the handshake allows us to perform that part with less overhead... that is, committing fewer resources until the handshake is completed. This will mean the timing of the on('session') event will change.

  3. Separating out the handshake allows us to experiment with alternative handshake protocols. While QUIC currently requires TLS 1.3, there is at least one other handshake pattern being looked at.

I've been putting off making the change because it's going to be fairly disruptive, but it's time to get started on it before progressing too much further on the http3 bits.

TODO: Fix alpn identifier in JavaScript

In the javascript API, alpn identifier is not being set properly in the QuicSession/QuicServerSession/QuicClientSession objects.

 const quic = require('quic');
 const s = quic.createSocket();
 const r = s.connect({alpn: 'zzz'})
 console.log(r.alpnProtocol); // undefined

ping

An interface to send QUIC ping frames would be really handy for long lived connections. It's also common in the existing QUIC prototype libraries that exist for javascript.

TODO: Fix compiler warning in node_quic_stream 

../src/node_quic_stream.cc: In function ‘void node::quic::{anonymous}::QuicStreamShutdown(const v8::FunctionCallbackInfo<v8::Value>&)’:                                                                                                                                        ../src/node_quic_stream.cc:459:53: warning: enumeral and non-enumeral type in conditional expression [-Wextra]
stream->Shutdown(family == QUIC_ERROR_APPLICATION ? code : NGTCP2_NO_ERROR);                                                                                                                                                                                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~

TODO: Verify streams opened out of order

QuicStream ... Implement test verifying that "A stream ID that is used out of order results in all streams of that type with lower-numbered stream IDs also being opened."

Type: test
Priority: high

Failure to compile debian Jessie

Older versions of g++ are unable to compile this project due to an issue with Malloc. I have not troubleshooted beyond that.

Debian Jessie (yes - unsupported by Debian) is one such example.

I'm not sure this needs to be resolved for now, just a FYI. Debian Stretch (current distribution) has no problems.

TODO: Implement QuicSocket proxy mode

This will allow received packet headers to be intercepted and forwarded on to a separate QuicSocket instance or endpoint, allowing a Node.js instance to be used as a QUIC passthrough.

Openssl & TLS 1.3

OpenSSL 1.1.1 has landed, and with it the TLS 1.3 support we need... however, there are two patches we need to bring in to make this work correctly:

Just leaving this here as a heads up. I'll be bringing these in next week but need to do some other testing to make sure they don't break anything else in core.

TODO: Implement special handling for out of packet numbers error

A QuicSession is limited to a fixed maximum number of packets that may be sent. Once this number is exhausted, the connection must be torn down. We should likely handle this case in a special way that lets the user attempt to recover by quickly opening a new session if they want.

Also need to figure out how to test this.

strange export design

Right now the structure of the quic exports is this:

createSocket.createSocket = createSocket;
module.exports = createSocket;

I would strongly recommend just doing module.exports = { createSocket };, as we know from experience with buffer and eventemitter that setting module.exports itself as an exported value is undesirable.

TODO: QuicSession/QuicStream ... Implement a prioritization scheme

Unlike HTTP/2, QUIC/HTTP3 does not provide a built in priority mechanism. Instead, it relies on the application to provide prioritization. ngtcp2 essentially leaves this entirely up to us. Currently, we send data in the order streams were created, rather than in any priority order. At some point, we might look into implementing a priority queue for data that is pending to be sent.

Type: functionality/test

Sever -> Client client address not available

Description: session.address returns the socket's address
Direction: Client->Server on Server

console.log(clientSession.address)

{ address: '0.0.0.0', family: 'IPv4', port: 1443 }

TODO: Ensure path validation is happening correctly

When a connection is being migrated to a new connection, the path needs to be validated. Some of the mechanism for this is already in place. It needs to be completed and verified that it is working correctly.

TODO: Implement support for NEW_TOKEN

Currently waiting on support for NEW_TOKEN frames to be implemented by ngtcp2. Once implemented, we need an API to allow an endpoint to explicitly use it.

TODO: Implement stateless reset

Stateless reset support is going to be a bit tricky. An endpoint sends a stateless reset when it does not have access to connection state any longer, but that means we need to keep track of CIDs and their correspnding stateless reset tokens in a way that can survive a crash (which is ironic to say the least). Need to figure out how to implement this protocol feature.

TODO: Implement a maximum retransmission limit

QuicSocket/QuicSession ... Implement a maximum retransmission limit. Currently, a QuicSession will attempt retransmission an unlimited number of times. This should be constrained by some user-specific limit with a reasonable default. The retransmission here is used to handle loss packets.

Type: functionality/test
Priority: high

Design Approach

Just wanted to drop some implementation notes into this since there are some others looking at pitching in. Will be updating this as we go.

The UDP and TLS mechanisms need to happen entirely at the native layer. The implementation here is not building on the existing dgram or tls modules that exist in core. The UDP socket, TLS context, and interaction with the ngtcp2 APIs will happen entirely at the native layer.

More to come...

Current Checklist of stuff to do

Just to give folks an idea of the full list of things still being worked on:

Procedural

  • Convert this checklist into a project board
  • Open PR on nodejs/node adding initial QUIC implementation behind the configure switch

Functional

  • Build
    • Implement configure build switch to optionally enable building QUIC support
  • Error Handling
    • QuicSession HandleError is broken in some scenarios. Causes a segfault. Need to investigate where and when
    • Connection timeout #39
    • Ensure proper handling and use of QUIC session and crypto error codes
    • When out of packet numbers error occurs, we may want implement a special error for this so that this case can be detected.
    • Need to figure out how to test various error edge cases (such as out of packet number errors)
  • Memory
    • Fill out memory tracking
    • Use stack allocated packet buffers rather than malloced if possible
  • Socket/Session/Stream Lifecycle
  • Protocol
    • Ensure that retransmission is occurring properly. In general, packets are being retransmitted but dropped packets having a fairly significant cost currently. Retransmission can be more efficient and needs to be looked at in detail.
    • Ensure that path validation is occurring correctly and is tested
    • Implement ability to optionally send stateless reset. This is going to be a bit tricky. An endpoint sends a stateless reset when it does not have access to connection state any longer, but that means we need to keep track of CID's and their corresponding stateless reset tokens in way that can survive a crash. But we don't want to keep them around forever.
    • Ensure that moving to a server preferred address and migration to a new connection can actually happen simultaneously
    • Complete support for server preferred address. Upon receiving and validating a server preferred address, client should migrate to the preferred address automatically.
    • Currently, in most cases, setting stream fin requires an empty stream frame with fin bit set. See if we can optimize that further
    • Make use of final size parameter when known (at the very least, there should be a getter on the QuicStream)
    • Wait for NEW_TOKEN support to be implemented by ngtcp2
    • The basic API for sending SERVER_BUSY responses is in place but ngtcp2 does not yet fully support sending CONNECTION_CLOSE frames in Initial packets. Until that is implemented, the SERVER_BUSY implementation is disabled and the test is not yet completely implemented. (Update: I believe landing #54 will provide the necessary support for sending CONNECTION_CLOSE in an initial packet)
  • Security
    • Implement various slow loris style DOS mitigations
    • Verify amplification attack mitigations
  • Performance Tracking
    • Implement the JavaScript side of the perf tracking histograms
  • Features
    • Implement QuicSocket proxy mode. This will allow received packet headers to be intercepted and forwarded on to a separate QuicSocket instance, allowing a Node.js instance to be used as a QUIC passthrough.

Optional/Lower Priority

  • Eventually, we will want to implement support for receiving and validating ICMP packet too big messages as a mechanism for detecting failures in QUIC packet transmission due to MTU packet size.
  • Determine whether we want to support zero-length connection IDs. This is optional by the specification. It's not yet clear how ngtcp2 supports zero-length connection IDs. Need to test.
  • Revisit the flow control / backpressure strategy. We may want to allow multiple flow control strategies to allow performance to be tuned.
  • openStream() API ... specifically, ability to specify an initial chunk of data to include when opening the stream.

Completed:

  • Connection migration test is currently broken, need to verify that it's working and ensure completed implementation PR: #50
  • Ensure that all C++ objects can be destroyed immediately in the current callstack without requiring nextTick or setImmediate deferral.
  • Ensure application close on QuicSessions
  • Ensure that close and destroy are re-entrant tolerant
  • Catch out of packet numbers error. The code will do a SilentClose.
  • Only prefer address validation once per connection per address? Make this configurable https://github.com/nodejs/quic/pull/48/files
  • Verify that retransmissions are happening correctly. Update: regular stream retransmissions are happening as necessary but handshake is still iffy.
  • Verify that STREAM_RESET and STOP_SENDING are handled appropriately
  • Improve handling of configuration and transport params
  • Implement exponential backoff on the sending of CONNECTION_CLOSE frames during closing period.
  • Ensure that STOP_SENDING is not sent after receiving a STREAM_RESET from the peer
  • Ensure that only CONNECTION_CLOSE frames are sent in the closing state, Ensure that absolutely no frames in the draining state.
  • Verify how sending of version negotiation packets is handled. e.g. are they sent for 0RTT packets?
  • Ensure that crypto handshake buffer protections are working
  • Implement handling when valid stateless reset is received
  • QUIC recommends using path maximum transmission unit discovery but libuv and Node.js currently provide no way of implementing this. We should revisit this at some point later but for now, we cannot support PMTUD.
  • Determine if we want to support latency spin bit in any way? ngtcp2 currently does not expose an API for dealing with the spin bit. Nor does it expose the necessary information we need to implement it properly ourselves. Therefore, until ngtcp2 supports it, we won't support it.
  • Determine how and if we ever want to support multiple QUIC protocol versions. Update: for now, we're only going to support one QUIC protocol version at a time because that's what ngtcp2 is limited to.
  • Ensure that a server completely ignores invalid or unexpected frames
  • alpn is absolutely required so ensure that it's always there. Error if not provided
  • Verify stream commitment attack mitigations
  • Avoid stream commitment attacks. Verify that implicitly opened streams do not commit resources unless data is actually sent.
  • We need an API to trigger a key update
  • Implementing a pool of connection IDs to make generation more efficient Determined there's no performance advantage realized by this relative to the cost of implementation
  • Determine if there's any reason to expose an API for ping frames. Determine how we could ever support responses. For the time being, there's no reason for us to support PING frames directly. ngtcp2 uses them as it determines it is necessary and there are ways we can monitor the aliveness and round trip times without a dedicated ping API.
  • Determine if there's any way to support extension frames with ngtcp2. ngtcp2 currently does not expose any API we can use to encode or decode extension frames. Until it does, there's nothing we can really do to support them.
  • Determine whether we want to expose an API to force a QuicSession to use a new connection ID. Changing the CID is permitted by the specification, we just need to decide whether to expose an API for it. Use of such an API won't be common but there is an argument to be made about having it available for privacy/security reasons. ngtcp2 currently does not provide an API for supporting this. So until it does, there's nothing to do.
  • Determine api for supporting extension transport parameters ngtcp2 currently does not support the ability to use extension transport params. So until it does, there's nothing to do.
  • Verify ngtcp2 support for ECN libuv currently does not provide access to the ECN bit for UDP, making it impossible for us to support use of ECN at the current time.
  • Determine whether we should allow disabling the idle timeout at all. There are many reasons why we shouldn't allow disabling it. We're not going to allow disabling the idle timeout at the current time. There are too many reasons to have it there. A user who really wants to can set the timeout to a very large value.

TODO: Tests

Need to begin a concerted effort around tests test and more tests.

Finish SERVER_BUSY support

The basic mechanism for SERVER_BUSY is in place but needs to be finished pending completed support for sending CONNECTION_CLOSE in an initial packet.

Retransmissions

Retransmission is generally working as of PR #34 ... there is an issue when handshake frames are dropped, however, and there are some cases where transmissions stalls due to lost frames. Need to investigate further.

TODO: Investigate segfault in QuicSession::Destroy

There is an intermittent segfault happening in QuicSession::Destroy when running the test-quic-serverbusy.js test in #85. Happens once every 10-15 runs. Seeing it primarily on Windows but occasionally happens on Linux. Need to investigate.

TODO: Implement various slow loris style DOS mitigations

Mitigations:

  • Limit the number of connections per remote IP address
  • Ability to manually toggle SERVER_BUSY status
  • Data Rate Monitoring (via Rate & Size Histograms
  • HTTP Header Reception Timeout (Http3Application and QuicStream level)) - This can be implemented by setting a timer in JavaScript that is cleared when one of the header events is triggered.
  • Configurable Limit on the total number of connections per QuicSession (PR: #299)
  • Handshake Completion Timeout (QuicSession level)

TODO: Make use of final QuicStream size

When the final size of a QuicStream is known, it should be exposed to the JavaScript side. Likewise, we are currently not exposing any bytes written/received/queued statistics for the QuicStream

TODO: SendFile/SendFD support

Implement an API similar to http2 that allows sending a file entirely at the native layer, bypassing the streams API and avoiding bringing any data into the javascript layer

Implement Build Configure Switch

Implement temporary configure build switch to optionally enable building QUIC support.

Windows:

vcbuild projgen experimental-quic

POSIX:

./configure --experimental-quic

EDIT: updated enable-experimental-quic to experimental-quic as explained in PR #83 (comment)

Error when trying to build

@danbev ... I'm seeing the following when I attempt to build...

In file included from ../deps/ngtcp2/lib/ngtcp2_acktr.h:32:0,
                 from ../deps/ngtcp2/lib/ngtcp2_acktr.c:25:
../deps/ngtcp2/lib/includes/ngtcp2/ngtcp2.h:51:10: fatal error: ngtcp2/version.h: No such file or directory
 #include <ngtcp2/version.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from ../deps/ngtcp2/lib/ngtcp2_buf.h:32:0,
                 from ../deps/ngtcp2/lib/ngtcp2_buf.c:25:
../deps/ngtcp2/lib/includes/ngtcp2/ngtcp2.h:51:10: fatal error: ngtcp2/version.h: No such file or directory
 #include <ngtcp2/version.h>
          ^~~~~~~~~~~~~~~~~~

Tests, test, and more tests

Hey @nodejs/quic

The implementation is getting to the point where we need tests, lots of tests. If you'd like to find a way of jumping in to help with the implementation, that's probably the one area that would be the most valuable right now...

[HEADS UP] Rebasing Master, Squashing QUIC commits

Heads up @nodejs/quic (@danbev and @addaleax in particular)... I'm going to be rebasing nodejs/quic master and squashing a large number of the quic specific commits down in order to make further rebasing easier. As it stands now, we're a couple hundred commits ahead which makes rebasing quite a bit more difficult. I'll squash first, then rebase.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.