What is an NTRIP Caster?
NTRIP means Networked Transport of RTCM via Internet Protocol. A source or NTRIP Server sends correction data to a named mountpoint. The caster validates the source, publishes stream metadata, and forwards the binary data to authorized NTRIP Clients. The correction calculation may occur in a base receiver or network engine; the caster is primarily the controlled transport and distribution layer.
A professional caster adds operational controls: client and source limits, configurable concurrent connections per account, tenant isolation, event reasons, activity timers, metrics, and an administration API. It can host local bases, network products such as VRS, and selected streams relayed from partner casters.
XYZRVB connects the caster to a GNSS control center so operators can correlate station data, rover sessions, GGA positions, RTK modes, and disconnections instead of relying on terminal output alone.
Source, caster, client, and rover architecture
The base receiver is configured with valid reference coordinates and RTCM messages. After source authentication, the caster continuously reads bytes. A rover performs a GET request for a mountpoint, usually with Basic authentication and a User-Agent. After a successful response, the same connection carries binary RTCM.
A rover may send NMEA GGA back to the service. VRS and nearest-station workflows depend on that position. The server may also use GGA for distance policies and monitoring, provided the requirement is compatible with the equipment.
When an external stream is imported, the local caster becomes an upstream NTRIP client. XYZRVB opens the remote session only when an authorized local rover requests the selected mountpoint, shares the relay when appropriate, and closes it after an idle period.
In the XYZRVB relay model, one external-caster subscription and upstream credential can serve several rovers on the same mountpoint through one shared upstream connection. Each different mountpoint opens a separate upstream connection. If the external caster forbids simultaneous connections using the same credential, two points require two credentials or subscriptions and three require three. If reuse is allowed, the same access may serve several points within the provider’s contractual limits.
NTRIP v1 and NTRIP v2
NTRIP v1 uses HTTP/1.0-like exchanges with historical conventions. Many receivers expect ICY 200 OK after a successful client request, and older sources use the SOURCE request style. Compatibility with these behaviors remains important in deployed GNSS hardware.
NTRIP v2 aligns more closely with HTTP/1.1, including Host and Ntrip-Version headers and a standard HTTP 200 response. The body is still a long-lived binary stream. Header parsing must stop exactly at the blank line before RTCM bytes begin.
A TLS ClientHello sent to a plain NTRIP port is binary and must not be logged as a corrupted request line. Secure NTRIP requires a TLS-enabled listener or a compatible termination layer. Client capability should be tested rather than assumed.
| Aspect | NTRIP v1 | NTRIP v2 |
|---|---|---|
| Application style | HTTP/1.0-like historical conventions | HTTP/1.1-aligned exchange |
| Successful stream response | Commonly ICY 200 OK | HTTP/1.1 200 OK |
| Host header | Often missing on older devices | Normally present |
| Deployment | Broad legacy receiver support | Preferred for new implementations |
Sourcetable and mountpoints
The sourcetable is the textual catalog returned at the caster root. STR records describe streams; CAS and NET records describe caster and network information. A stream entry can include format, message list, constellations, country, approximate coordinates, NMEA requirement, and other properties.
Mountpoint names should be short, stable, and documented. The caster must filter the table by tenant and reject direct requests for undeclared or unauthorized streams. A published stream that never works and an accepted stream that is never published are both operational defects.
XYZRVB can retrieve an upstream sourcetable, let the tenant select individual mountpoints or import all of them, preserve the originating service label, and merge the selected STR entries into the tenant table. Duplicate local and upstream names are rejected.
RTCM transport and binary integrity
RTCM 3 frames begin with 0xD3, include a payload length, and end with a 24-bit CRC. TCP read boundaries do not match frame boundaries, so parsers retain incomplete data between reads. The caster itself can forward bytes immediately and decode selected messages in parallel for monitoring.
Text encoding must never be applied to RTCM. Windows and Debian transmit the same payload when byte arrays and network streams are used correctly. Text is limited to the request, headers, sourcetable, and NMEA sentences.
Slow or disconnected clients must not block the source. Asynchronous bounded writes and prompt removal of failed sockets protect other rovers. Logging every packet at Debug level may create more disk load than the actual correction traffic.
Authentication and security
Basic authentication does not provide encryption. TLS or a private network protects credentials and correction data in transit. The control API should always use HTTPS because it manages accounts, mountpoints, and upstream secrets.
Each rover credential has an administrator-defined concurrent-connection limit. Shared credentials are supported and each session retains its own connection number. For unambiguous physical-rover attribution, use one credential per rover with a limit of 1. IP addresses and MAC addresses are not reliable remote identities; client certificates are stronger only when the operator manages the certificate lifecycle.
Multi-tenant authorization combines the requested host or dedicated IP, the account, and the resource. Upstream caster configuration also requires outbound-address validation, response-size limits, timeouts, and protected password storage.
Performance and availability
Capacity planning covers active sources, clients per source, total sockets, bandwidth, memory, logging, and file descriptors. Limits on header size, initial read time, and upstream sourcetable size prevent individual requests from consuming unbounded resources.
Useful metrics include source age, active sessions, bytes in and out, authentication failures, disconnection reasons, and session duration. System CPU, available memory, disk space, and network errors provide the infrastructure context.
A service manager such as systemd restarts the process after failure and runs it independently of an SSH terminal. Deployment still needs backups, controlled restart behavior, and verification with a real long-lived NTRIP client.
NTRIP Caster FAQ
What is the difference between an NTRIP source, caster, and client?
The source injects correction data, the caster authenticates and distributes named streams, and the client selects a mountpoint and receives the stream. A base receiver commonly acts as the source and a rover as the client.
Can NTRIP v1 and v2 be supported together?
Yes. A compatible caster can understand historical NTRIP v1 behavior such as ICY 200 OK and modern HTTP/1.1-based NTRIP v2 requests.
Does standard NTRIP encrypt credentials and corrections?
Not by itself. Basic authentication is only encoded. TLS, a compatible secure listener, or a private network is required when transport encryption is needed.
What is a mountpoint?
A mountpoint is the stable logical name of a correction stream in the caster sourcetable. It may identify a physical base, a network product, a nearest-station service, or an authorized upstream relay.
How many subscriptions are required to relay an external caster?
In the XYZRVB relay model, one upstream subscription and credential can serve several rovers on the same mountpoint through a shared upstream connection. Each different mountpoint requires a separate upstream connection. If the external caster forbids simultaneous connections using the same credential, one credential or subscription is required per open mountpoint. If reuse is allowed, the same access may be used within the provider’s terms.
How can several rovers sharing one account be identified?
Every session retains a distinct connection number even when several rovers share a credential. For immediate attribution of each position and event to known equipment, create one credential per rover and set its concurrent-connection limit to 1.