28 releases

new 0.6.23 Mar 2, 2025
0.6.21 Jan 30, 2025
0.6.15 Dec 28, 2024
0.6.11 Nov 27, 2024
0.3.0 Mar 22, 2024

#224 in Network programming

Download history 77/week @ 2024-11-13 171/week @ 2024-11-20 152/week @ 2024-11-27 170/week @ 2024-12-04 317/week @ 2024-12-11 5/week @ 2024-12-18 121/week @ 2024-12-25 5/week @ 2025-01-01 166/week @ 2025-01-08 336/week @ 2025-01-15 115/week @ 2025-01-22 145/week @ 2025-01-29 13/week @ 2025-02-05 7/week @ 2025-02-12 144/week @ 2025-02-19 154/week @ 2025-02-26

326 downloads per month

MIT/Apache

150KB
4K SLoC

moq-relay

moq-relay is a server that forwards subscriptions from publishers to subscribers, caching and deduplicating along the way. It's designed to be run in a datacenter, relaying media across multiple hops to deduplicate and improve QoS.

Required arguments:

  • --bind <ADDR>: Listen on this address, default: [::]:4443
  • --tls-cert <CERT>: Use the certificate file at this path
  • --tls-key <KEY> Use the private key at this path

This listens for WebTransport connections on UDP https://localhost:4443 by default. You need a client to connect to that address, to both publish and consume media.

HTTP

Primarily for debugging, you can also connect to the relay via HTTP.

  • GET /fingerprint: Returns the fingerprint of the TLS certificate.
  • GET /announced/*prefix: Returns all of the announced tracks with the given (optional) prefix.
  • GET /fetch/*path: Returns the latest group of the given track.

The HTTP server listens on the same bind address, but TCP instead of UDP. The default is http://localhost:4443. HTTPS is currently not supported.

Clustering

In order to scale MoQ, you will eventually need to run multiple moq-relay instances potentially in different regions. This is called clustering, where the goal is that a user connects to the closest relay and they magically form a mesh behind the scenes.

moq-relay uses a simple clustering scheme using MoqTransfork itself. This is both dog-fooding and a surprisingly ueeful way to distribute live metadata at scale.

We currently use a single "root" node that is used to discover members of the cluster and what broadcasts they offer. This is a normal moq-relay instance, potentially serving public traffic, unaware of the fact that it's in charge of other relays.

The other moq-relay instances accept internet traffic and consult the root for routing. They can then advertise their internal ip/hostname to other instances when publishing a broadcast.

Cluster arguments:

  • --cluster-root <HOST>: The hostname/ip of the root node. If missing, this node is a root.
  • --cluster-node <HOST>: The hostname/ip of this instance. There needs to be a corresponding valid TLS certificate, potentially self-signed. If missing, published broadcasts will only be available on this specific relay.

Authentication

There is currently no authentication. All broadcasts are public and discoverable.

However, track names are not public. An application could make them unguessable in order to implement private broadcasts.

If security/privacy is a concern, you should encrypt all application payloads anyway (ex. via MLS). moq-relay will only use the limited header information surfaced in the MoqTransfork layer.

Dependencies

~29–51MB
~1M SLoC