# Reporting Relay

`report_sql.py` can be the sole client of the FreeDMR TCP reporting socket and
provide a compatible downstream socket for the live dashboard. This avoids
placing multiple reporting consumers on the live server while retaining the
existing netstring protocol.

The existing six positional arguments are unchanged. Enable the relay with:

```sh
python report_sql.py freedmr 4321 dbhost dbuser dbpassword logs \
  --relay-interface 127.0.0.1 --relay-port 4322
```

Configure FDMR Monitor to connect to relay port `4322`. Use an explicit
container-facing interface instead of `127.0.0.1` when the dashboard runs in a
different container, and restrict access to that interface at the network
boundary. Report configuration and bridge-state messages contain trusted
Python pickle data and must not be exposed to untrusted clients.

The relay forwards upstream messages unchanged and caches only the latest
configuration and bridge-state messages so a newly connected dashboard can be
initialized immediately. SQL storage accepts both legacy events and extended
events with trailing origin fields:

```text
START: type,event,trx,system,streamid,peerid,subid,slot,dstid,source_server,source_rptr
END:   type,event,trx,system,streamid,peerid,subid,slot,dstid,duration,source_server,source_rptr
```

Legacy events remain valid and are stored with null origin columns. The relay
is optional; omitting `--relay-port` preserves the previous importer behavior.

## Multiple FreeDMR backends

`report_mux.py` combines reporting from multiple FreeDMR backend processes
into one compatible reporting socket. It is used by the HDStack container
profile and can also be run directly:

```sh
python report_mux.py --listen-interface 127.0.0.1 --listen-port 4321 \
  --client 127.0.0.1 \
  --backend 1,127.0.0.1,4322 --backend 2,127.0.0.1,4323
```

Backend numbers are explicit and must be unique. Configuration keys, bridge
member system fields and bridge-event system fields are prefixed with that
number, for example `1:SYSTEM-001`. Other fields are preserved. The MUX
reconnects to each backend independently and a reporting-source failure does
not affect the radio proxy. Its backend connections remain open between
updates and accept bounded reporting frames up to 10 MiB so populated worker
snapshots do not trigger Twisted's smaller default netstring limit. A lost
backend connection is reported with its backend number and is re-established
independently. See [hdstack.md](hdstack.md) for the generated container
topology and configuration.