Waarom we géén traditionele dedicated server gebruikten – en waarom dat juist de sleutel was

Wanneer bedrijven VR inzetten voor training, assessments of simulaties, komt er al snel een technisch probleem naar boven:
hoe verbind je meerdere VR-headsets én externe viewers, veilig, betrouwbaar en schaalbaar, zonder een logge infrastructuur?

Voor VRMADA, een bedrijf gespecialiseerd in VR-oplossingen en de makers van UltimateXR, kreeg ik precies die uitdaging op mijn bord.

De klassieke aanpak werkt hier niet

In veel multiplayer-oplossingen zie je één vast patroon:

• Een zware dedicated server
• Meerdere kamers en sessies
• Clients die volledig afhankelijk zijn van die server

Maar in VR ligt dat fundamenteel anders.

Elke gebruiker brengt meerdere datastromen mee:

• De headset
• Twee controllers
• Continue positie-, rotatie- en interactiedata

Dat betekent: meer data, hogere frequentie, lagere foutmarges.
Een traditionele Unity dedicated server zou hier onnodig duur, complex en kwetsbaar worden.
En belangrijker nog:

Als die server eruit ligt, ligt alles eruit.

Dat was onacceptabel voor een enterprise-omgeving.

De gekozen architectuur: relay + slimme hosts

In plaats van één centrale alles-regelende server, hebben we het probleem omgedraaid.

• De VR-headset draait zelf de sessie
• De headset is tegelijk host én client
• Externe kijkers (bijvoorbeeld admin-PC’s) verbinden simpelweg met die sessie
• Een relay server faciliteert alleen het verkeer

De voordelen:

• Geen zware serverlogica
• Geen complexe session lifecycle
• Minimale server resources
• En vooral: hoge betrouwbaarheid

De relay is puur een doorgeefluik — lichtgewicht, schaalbaar en robuust.

Waarom Promul (en waarom niet zomaar)

Voor deze setup heb ik gekozen voor Promul.
Op papier leek dit ideaal:

• Relay-functionaliteit
• Peer-to-peer-achtige verbindingen
• Unity-integratie

Maar in de praktijk bleek al snel:
de basis was er, maar het was niet af.

Problemen die we tegenkwamen

• Packet layers die niet consistent werden toegepast
• Onbetrouwbare handshake-flows
• Kamers die handmatig via curl moesten worden aangemaakt
• Geen echte automatisering

Dat is niet houdbaar in een productie-omgeving.

Volledige automatisering van het kamersysteem

De eerste stap was structuur aanbrengen.
Ik heb ervoor gezorgd dat:

• De Unity Transport component direct een kamernaam of ID kan meegeven
• De relay server automatisch:
  • Een room aanmaakt
  • Sleutels voorbereidt
  • De sessie initialiseert

Geen handmatige calls meer.
Geen losse scripts.
Alles gebeurt automatisch bij connectie.

Beveiliging: HTTPS was pas het begin

Daarna heb ik de relay server ondergebracht in ASP.NET Core, inclusief:

• SSL
• Publiek domein
• Correct certificaatbeheer

Dat was relatief rechttoe rechtaan.
Maar toen kwam het echte werk.

Encryptie op packet-niveau: waar het écht misging

De opdracht vereiste end-to-end encryptie van alle data.
In eerste instantie testten we eenvoudige technieken, zoals byte inversion van inkomend en uitgaande data.

Maar zelfs dat werkte niet.

We kregen constant:

• Malformed packets
• Bad data
• Timeouts na handshake

Na diepgaand debuggen bleek het probleem fundamenteel:
Promul paste packet layer logica niet overal consequent toe.

Sommige codepaden (zoals handshake en control-messages) omzeilden de packet layers volledig.

De doorbraak

In plaats van blijven “plakken” op bestaande lagen, heb ik het systeem teruggebracht naar de kern:

• Alle packet layer logica verwijderd
• Alleen gekeken naar:
  • Waar data binnenkomt
  • Waar data eruit gaat
• Dáár encryptie/decryptie toegepast

Het resultaat?
Zelfs de simpelste encryptie werkte ineens foutloos.

Resultaat van Deel 1

Aan het einde van dit traject hadden we:

• Een stabiele relay server
• Volledig geautomatiseerde rooms
• Hosts die tegelijk client zijn
• Betrouwbare, voorspelbare data-flows

Maar…
beveiliging was nog niet klaar.