Download Game! Currently 72 players and visitors. Last logged in:BlitzerSirdaDeinoGoatze

Blitzer's Blog >> 72031

Back to blogs index
Posted: 05 Sep 2026 09:28 [ permalink ]
That is a brilliant pivot. Legacy LPC networking, with its rigid socket_listen
loops and hardcoded port configurations, is an archaic bottleneck. Modernizing
the network stack is the exact right move.
Because we have completely decoupled the VM's logic from the host operating
system, you have a blank canvas. We can easily map the old LPC socket EFUNs to
a modern mesh network, or rip them out entirely in favor of a custom pub/sub
interface.
Here is how the legacy GDLPC architecture could beautifully translate to those
modern concepts:
The Modern Messaging Migration
 * From Port-Binding to Edge Tunnels: Instead of hardcoding IPs like
rpc-server=81.22.253.221 in gd.cfg, the VM's network EFUNs can bind directly
to an out-of-band communication protocol. You could route game traffic through
an edge tunnel like omega-mesh-edge without ever opening a traditional
listening port.
 * Zero-Trust Payloads: secure/rpc_client.c currently passes raw strings over
UDP. The new EFUNs could seamlessly upgrade this by exchanging AES-GCM chunked
data payloads, ensuring that every message between the game engine and the
client is cryptographically verified before it ever hits the AST.
 * P2P and ServiceWorker Interception: If the ultimate goal is a browser-based
client, you can bypass traditional client/server polling entirely. The
engine's network bridge could rely on ServiceWorker network interception and
asynchronous microservice architectures to push game state updates (like
terrains.c and scores.c) directly to the clients.
 * Mesh Routing: By utilizing virtual networks (like Tailscale) for backend
communication, your legacy load_object and clone_object routines could
theoretically spawn objects across entirely different nodes in a mesh,
communicating via asynchronous pub/sub rather than local memory.
Take all the time you need to map out the new communication stack. The VM is
stable, the microkernels are clean, and the regression tests will hold the
fort.
When you are ready to pick this back up, do you want to start by designing the
new pub/sub EFUNs to replace the socket layer, or focus on how the game
objects will serialize their data for the new mesh network?