bbc / nghq Goto Github PK

An implementation of Multicast QUIC https://tools.ietf.org/html/draft-pardue-quic-http-mcast-07

License: MIT License

Makefile 2.06% Shell 0.11% M4 4.43% C 93.40%

nghq's Introduction

nghq

nghq is a HTTP framing layer that aims to provide support for the HTTP/QUIC mapping for running HTTP over IETF QUIC.

The nghq API is modelled after that of nghttp2. The application owns the communicating socket and feeds data into the library via a series of calls. The application is expected to act on callbacks from the library. There are a couple of important points to note:

nghq does not own the socket. The application is expected to read data from the socket and provide it to the library. When the library has some data to send, it will call back into the application with the data to be sent on the application's socket.
nghq does not do any encryption or decryption of the packets received. It is up to the application to manage the TLS context. The encrypt and decrypt callbacks will be fired when the library needs encryption or decryption to be done.

The public API is documented here. In addition, the library's public header file nghq.h has comment blocks for every function and callback listed above it which also serve as documentation.

Some helpful sequence diagrams, showing the expected interaction between a client/server application and nghq can be found here.

Caveats

NOTE: In its current form, nghq implements only the parts of the QUIC and HTTP3 specifications required by draft-pardue-quic-http-mcast-07.

In particular, it only supports a profile of the draft-ietf-quic-transport-29, and draft-ietf-quic-http-29.

Getting Started

If you wish to build and run the examples, you will also need libev version 4.0 or above.

nghq uses the ls-qpack library to perform QPACK header compression and decompression routines. The ls-qpack library is included as a linked git submodule, which should be initialised and updated as part of the bootstrap script.

The build system itself uses Automake. To build the software, do the following:

$ ./bootstrap
$ ./configure
$ make

Options

To enable some fairly verbose debugging output from the library, you can supply the --enable-debug option to the configure script. This will write output from nghq to the command line when the library is run. Debugging output is disabled by default.

To install the software, use make install. To change where nghq will be installed, use the prefix configuration parameter as below:

$ ./configure --prefix=/home/roadrunner/nghq-target
$ make install

Running the examples

If you had libev installed when building, then the examples in the examples/ directory will be built. Currently, there is a simple multicast sender and a multicast receiver application. Run them with --help to see the available runtime options.

Credits

License

This software is licensed under an MIT License. See the COPYING file for more.

Contributing

If you have a feature request or want to report a bug, we'd be happy to hear from you. Please either raise an issue, or fork the project and send us a pull request.

Authors

This software was written by Sam Hurst with additional contributions by David Waring.

Copyright

nghq's People

Contributors

Stargazers

Watchers

Forkers

bagder rafee maxime-beck jwinarske elviswoo ahrime evilmonkey19

nghq's Issues

Problem trying examples

Hi!

First of all, congratulations for all the work done. I'm currently doing my final degree project about QUIC Multicast for live-streaming over HTTP. Looking on github I found your library and I also read your paper about it. I think it is pretty amazing do all that hardwork almost alone. Congratulations again!

At the moment, I have already build a network testbed with which I willing to try you software in a "real environment". I can pass you the testbed if you want. I'm using Ubuntu 18.04 LTS lxc images as OS. When I finish all the paper I will also give it to you.

Well, the problem is that trying to build the library and the examples/multicast-sender and examples/multicast-receiver, I found the following problem with some compilation maybe:

I would be awesome If you can help me!

Thank you again,
Enric.

P.D: Sorry for my english :'). It's clear that I'm not from England jeje.

SETTINGS parsing assumes fixed-length fields

Discussion on quicwg/base-drafts#1556 highlighted that there is a problem with our parsing of some SETTINGS parameters as defined in draft 09 (and 13, current at time of writing).

The offending line is https://github.com/bbc/nghq/blob/master/lib/frame_parser.c#L235

We should observe how the HTTP/QUIC issue is resolved before committing to a fix.

multicast-receiver crashes with ERR_PROTO

The behaviour of multicast-receiver is unstable i.e. it receives a file/folder and keeps waiting for any new packet (which is okay as per flow). But if I send again a file/folder it throws ‘ERR_PROTO’ and ‘nghq_session_recv()’ fails with code -1. I did enable the debug for both NGHQ and NGTCP2 during setup but somehow NGTCP2 library does not debug anything. See attached logs

multicast-sender_log.txt
multicast-receiver-error_log.txt

PS: Oracle VirtualBox VM (Ubuntu v18.04.2 LTS ) with libev v4.25

Including ngtcp2 as Submodule

Is it possible to include ngtcp2 as submodule? I think that will make installation and using the application much simpler.

frame_creator:create_frame_headers_frame abstraction is wrong for draft 13+

frame_creator.c includes this:

/*
 *  0                   1                   2                   3
 *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 * |                    Optional Push Stream Header                |
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========
 * |           Length (i)       ...|    Type (8)   |   Flags (8)   |  Frame HDR
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========
 * |                        Header Block (*)                       |  HEADERS
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Payload
 */

This was never a valid abstraction but it worked ok. However, with the changes that were made in HTTP/QUIC draft 13 this crutch makes life difficult.

We need to separate out unidirectional stream headers from the following frames or extension defined data that will be sent thereafter.