Monta un relay

Pon uno en marcha

tally-relay keygen > /etc/tally/relay.key

tally-relay --key /etc/tally/relay.key --max-upload 8Mbit/s --listen 0.0.0.0:10900 --beast-out 127.0.0.1:30105

--beast-out sirve cada recepción como BEAST simple para un decodificador local como readsb. No tiene autenticación, así que vincúlalo a loopback.

--stats-listen sirve en JSON lo que el relay sabe de cada receptor (GET /stations, y GET /stations/KEY con la clave en base64url): sesiones, primera y última vez visto, lotes, huecos de secuencia, mensajes por segundo, y la ubicación y el software que declara cada receptor. Vincúlalo también a loopback.

Para ejecutarlo como servicio, el tally-relay.service de la versión publicada ejecuta un relay como usuario dinámico, con su clave en /etc/tally/relay.key, sus argumentos en TALLY_RELAY_ARGS y su límite de subida en TALLY_RELAY_MAX_UPLOAD, ambos dentro de /etc/default/tally-relay.

En qué confía

Por defecto, un relay confía lo justo. Solo las claves que indiques con --accept-relay pueden conectarse como otro relay, y --upstream lo enlaza con otro relay. Cada feeder queda limitado por --max-feeder-bytes-per-sec, 256 KiB/s por defecto y comunicado al feeder de antemano, y las conexiones tienen un límite global y otro por dirección.

Qué sirve

Un suscriptor elige sus flujos y puede cambiarlos en cualquier momento:

• En bruto: los lotes firmados de cada receptor, por región, para la MLAT de los relays y para investigación. Una región es donde el receptor dice estar, nunca donde está una aeronave.
• Deduplicado: una copia de cada mensaje Mode-S, firmada por el relay como afirmación propia. Es el flujo que quiere la mayoría de los clientes, unos 30 Mbps para todo el mundo con 20 000 receptores.
• Posiciones: aeronaves localizadas por la MLAT de los relays, cada una firmada por el relay que la resolvió.

Cómo se reparten el trabajo los relays

Un feeder envía a los dos relays en buen estado más cercanos, en redes distintas. El más cercano significa dentro de una franja de tiempos de ida y vuelta, y dentro de esa franja cada feeder de una zona hace la misma elección, ponderada por la capacidad libre que declara cada relay, así que los feeders de una zona se reúnen en los mismos pocos relays. Un relay lleno redirige a un feeder nuevo al siguiente de la lista.

La MLAT de cada zona la hacen dos o tres relays, elegidos con el mismo tipo de regla compartida entre los relays que ofrecen capacidad de MLAT. Los demás relays que tienen feeders de esa zona les pasan sus datos en bruto, en un salto, así que los datos en bruto nunca viajan lejos.

Los datos se reparten por zona, como en BitTorrent. Los relays que tienen los feeders de una zona envían un número fijo de dos o tres copias, por muchos que las quieran. Cada flujo se divide en franjas, y cada relay que toma la zona reenvía su propia parte a unos cuantos más: reenviar esa parte es el deber que conlleva la zona.

Las zonas forman un árbol fijo, desde zonas pequeñas, pasando por regiones, países y continentes, hasta el mundo. Un relay toma zonas en el nivel que necesita y comparte en ese nivel, y cuando ha reunido todas las zonas bajo una más grande, puede ofrecer la grande como un único paquete.

Un suscriptor lento se desconecta, nunca se le espera. Recibir datos no le cuesta a un relay más que su servidor; lo que envía se factura, así que cada relay fija un límite de subida con --max-upload, y su factura nunca puede superar el límite por los segundos de un mes: 10 Mbit/s son como mucho unos 3,3 TB. El límite nunca se agota. Cuando se le pide más de lo que lleva, primero va el tráfico de control, luego las posiciones y los modelos de reloj, luego los datos en bruto hacia otros relays, y los suscriptores simples al final. Un feeder nuevo se rechaza mientras el límite no pueda llevar lo que el relay tendría que reenviar por él, y los suscriptores simples se desconectan antes que cualquier relay, primero los más pesados. Lo que cuesta un relay en los proveedores habituales está en la sección “What a relay costs” del README.

La regla de producción

Si dependes de los datos de Tally, léelos a través de un relay que montes tú, no del de otra persona. Así, otro operador solo puede perjudicar a los feeders que él transporta, y cada feeder publica en dos relays de redes distintas.