the software
Architecture
One process fans streams to many clients. Our field ingest is relay-pull from a receiver IPort. HA chapters wrap that same process — they do not change how the binary works.
NTRIP roles
| Role | What it is | In this lab |
|---|---|---|
| NtripSource | GNSS stream generator | Receiver IPort (raw RTCM TCP) |
| NtripCaster | Fan-out server on :2101 |
BKG Professional on EC2 |
| NtripClient | Pulls a mount | Rover / BNC / QC tools |
| NtripServer | Uploads to a caster | Not used in relay_iport |
The caster does not decode RTCM and does not do VRS. It terminates NTRIP and copies bytes.
Baseline path (relay_iport)
This is the normal setup — one caster, one AZ.
Terraform: examples/relay_iport → modules/caster. Inventory is
field_sources (IP/port/mount). Passwords and VPC IDs stay in tfvars.
One host. Host or process loss = stream down until you replace it. That is why the next chapters exist — not because the binary grew a cluster mode.
What HA adds next
Work through each chapter on its own — apply, understand, then destroy before the next stack so bills and state stay clear.
| Chapter | Example | Idea |
|---|---|---|
| Dual-AZ | relay_iport_ha |
Two warm casters, one shared NLB, same VIP |
| Multi-region | relay_iport_ha_mr |
One caster/NLB per region, Route53 failover DNS |
Each caster still relay-pulls the IPort on its own. Clients reconnect after a drain — no mid-stream handoff.
Module layout
| Path | Role |
|---|---|
modules/caster |
EC2, userdata, conf templates, optional NLB |
modules/bnc_client |
Optional BNC + RINEX pull client (HA drills) |
examples/relay_iport |
Baseline |
examples/relay_iport_ha |
Dual-AZ |
examples/relay_iport_ha_mr |
Multi-region |