Registration flow

ZMQ architecture

Registrations are shared toward the centralized registration servers, and then shared to each station. Communication occurs via ZMQ. Below is a high-level diagram, illustrating the flow of registrations to each station.

decoy registrar:

Detector tracks TLS flows, looks for first AppData from client, looks for elligator-tagged ciphertext, and extracts registration. Shares reg with application via zmq.

Then application ingests registrations in ingestRegistration() (https://github.com/refraction-networking/conjure/blob/46fea9be3592c26b8841d53438264af5b740a544/pkg/station/lib/registration_ingest.go#L129). If this is a detector-based registration, then share with API via tryShareRegistrationOverAPI().

When the Detector process creates a registration, it's first shared with the application (via ipc://@detector-workers which proxies to ipc://@detector that the application subscribes to. Both ipc://@detector-workers and ipc://@detector are launched by detect.c). The source will be Detector, and the application will do liveness testing (if for a v4 phantom). Once marked not live, the application will share with the registration server endpoint, rewriting the source to be DetectorPrescan.

This means the application could hear about the registration twice if its local detector picked up the decoy registration: once with source=Detector, and then with source=DetectorPrescan.

Registration API:

Here the registration API accepts the reg, and then shares it with all the stations (applications), but does not share with other reg server

Conclusion:

decoy registrations could be heard by 1 or more registration API servers (because each decoy reg could go past a different station, and each station reports to one registration API server), but other registration types should be partitioned across reg API servers.