Delivery zones¶

A zone is the site a viewer watches from. In a corporate network a site usually coincides with an office: the Moscow office has its own servers, St Petersburg has its own, and an employee has no reason to pull the broadcast across half the country when the picture is available in their own server room.

Zones answer one question: which server to send a viewer to when they have just opened a broadcast.

How a viewer lands in a zone¶

A zone is described by a list of subnets in CIDR notation — 10.10.0.0/16, 2a02:6b8::/32. IPv4 and IPv6 live in the same list.

When a viewer opens a broadcast, their address is matched against the subnets of every zone. The longest matching prefix wins — that is, the most precise description. This lets the network be described in layers: a wide zone for the whole company and narrow zones for individual offices inside it; an employee at an office lands in their own zone, while a guest from a subnet nobody described separately lands in the general one.

Servers are attached to a zone in their own settings: a zone is not a list of machines but an attribute of a machine.

The fallback zone¶

A zone may name a fallback zone — where to take a viewer when no live servers are left in their own. This is what turns an office server room failing from "the broadcast is gone" into "the broadcast is slower".

The fallback is a reference, not a copy: a chain of zones may lead further on, and a reference to a zone that does not exist yet is allowed — the chain simply ends there.

Why a corporate broadcaster wants this¶

The point of zones is not saving traffic as such but where the bottleneck sits. An all-hands is watched by every office at once, and the link between sites is the one place where a thousand viewers turn into a thousand streams. Zones keep that traffic inside the site: one stream travels between offices, not a thousand.

That is why zones are set up before the first big meeting, not after it.