< Back To MRTS

Case Study: MRTS SDK

Context

The MRTS SDK served as the shared runtime foundation for multiple distributed 3D training systems used by the United States Navy.

These trainers operated across networked peers in real time and were required to:

  • Maintain consistent simulation state across all participants

  • Function under strict government networking constraints

  • Avoid UDP

  • Avoid traditional client/server architectures

  • Scale to approximately 40 machines

  • Target real-time execution at 60 frames per second

Synchronization errors would invalidate training sessions, and bandwidth inefficiencies would degrade performance at scale.

I led the design and implementation of the SDK’s networking layer and messaging policy.

The Problem

The challenge was not simply transmitting state between machines.

The system needed to:

  • Preserve deterministic simulation behavior across peers

  • Avoid reliance on UDP-based messaging

  • Avoid centralized client/server topology

  • Operate efficiently at real-time frame rates

  • Support up to 40 participating machines

  • Enable record and playback without introducing a secondary state model

Pure peer-to-peer messaging risked nondeterministic ordering. A client/server approach was disallowed. UDP-based lightweight synchronization was not permitted.

The architecture had to satisfy performance, determinism, and compliance simultaneously.

Architectural Strategy

Peer-to-Peer with Authoritative Ordering

We adopted a peer-to-peer topology augmented by an authoritative host responsible solely for message ordering.

While all peers participated equally in simulation, the authoritative host defined the canonical message processing order. All machines processed state changes through an ordered pipeline to prevent divergence.

This approach preserved distributed interaction while centralizing sequencing authority without violating client/server constraints.

Ordering was treated as a first-class architectural guarantee.

Frame-Based Delta Batching

To meet scalability and bandwidth requirements, the SDK tracked and transmitted only state deltas occurring within each frame.

For every frame:

  • All state changes were collected.

  • Changes were batched into a single delta message.

  • The batched update was distributed to peers.

This design:

  • Significantly reduced bandwidth usage compared to full-state transmission.

  • Aligned network updates with the simulation’s frame cadence.

  • Reduced per-frame message overhead.

  • Maintained deterministic reconstruction across peers.

Bandwidth efficiency was achieved structurally rather than through post-hoc optimization.

Deterministic Replay as Architectural Consequence

The delta-frame model also enabled deterministic record and playback.

Because replay consisted of applying recorded delta frames in canonical order:

  • Simulation behavior could be reconstructed precisely.

  • Record files remained compact.

  • Debugging and validation improved significantly.

Replay fidelity emerged naturally from the synchronization model rather than requiring a parallel snapshot system.

Platform Impact

The networking and messaging architecture became foundational across MRTS trainers.

It provided:

  • Deterministic synchronization across distributed peers

  • Compliance with government networking constraints

  • Scalable performance targeting 40 machines at 60fps

  • Reduced bandwidth overhead

  • Consistent replay and validation behavior

Because these guarantees lived at the SDK layer, downstream trainer teams inherited them automatically. The design reduced fragmentation and established consistent distributed behavior across products.

Lessons Learned

Customer constraints do not limit architecture; they clarify it. When UDP and client/server models are disallowed, sequencing and state propagation must be owned explicitly. Determinism must be designed into the messaging layer, not inferred from topology. Aligning network communication with frame cadence simplifies reasoning and improves scalability. Platform architecture is most effective when its guarantees are structural and automatically inherited by all downstream systems.