DMSG on Skycoin Blog

DMSG-First, HTTP Fallback: The Default Is Now the Encrypted Overlay

Fri, 10 Apr 2026 00:00:00 +0000

The Default Changed, Quietly

For most of Skywire’s history, the visor talked to the network’s infrastructure services — Transport Discovery, Service Discovery, Address Resolver, Route Finder, Uptime Tracker, and the config bootstrapper — over plain HTTP. You could configure DMSG-HTTP transport instead, but it was opt-in, and relatively few visors used it. The majority of traffic between visors and services flowed over HTTPS on the public internet.

With the dual-endpoint services-config.json that landed over the past two weeks, that default has flipped. Every visor is now configured with both DMSG and HTTP endpoints for every service, and the visor tries DMSG first. HTTP requests happen only when DMSG is unavailable — as a fallback, not as the primary path. For operators who don’t change anything, the practical effect is that service requests stop leaving the encrypted overlay entirely.

DMSG Server Mesh and DMSG Server-Hosted Route Setup

Thu, 09 Apr 2026 00:00:00 +0000

Two Architectural Changes That Belong Together

Over the past two weeks, two changes landed in the DMSG layer that together offer significant flexibility in how Skywire deployments can be structured: DMSG servers can now peer with each other to form a mesh, and a DMSG server can optionally run a route setup-node as an integrated service on one of its DMSG ports.

The first change is deployed and in active use. The second is deployed in the DMSG server binary behind an enable_route_setup config flag, but visors on the public Skywire network are not currently configured to use DMSG servers as their route setup nodes. The existing standalone setup-node continues to serve public network traffic, and it has been doing so reliably — at the time of writing, the production setup-node has been online for 53,080 seconds (about 14.7 hours) without restarts or ephemeral port exhaustion, following the cumulative effect of the port leak fixes from the great DMSG bug hunt.

The Great DMSG Bug Hunt

Thu, 09 Apr 2026 00:00:00 +0000

How We Discovered and Fixed Thousands of Leaked Goroutines Per Day

For most of its existence, DMSG “worked.” Clients connected, streams opened, frames flowed, servers relayed traffic. But under real production load over long periods, something was quietly going wrong — goroutines accumulated, ephemeral ports stayed reserved past their natural lifetime, memory grew, and servers eventually needed to be restarted to clear the cruft.

Over the past three weeks, a systematic audit found and fixed thirty-two distinct bugs in the DMSG codebase, ranging from tiny off-by-one errors to fundamental resource management failures that were leaking tens of thousands of goroutines per day on production servers. This is a narrative account of that hunt: what was broken, how it was found, and what the pattern of the bugs reveals about the codebase.

Skywire Development Update — April 7, 2026

Tue, 07 Apr 2026 00:00:00 +0000

DMSG: Two More Server Goroutine Leaks

The DMSG server goroutine hunt continued — two more leaks found and fixed, both involving the server’s forwarding logic.

Bridged streams idle timeout (#372) — bridged streams (bidirectional copy between two clients through the server) were blocking forever on io.Copy Read when one side disconnected without cleanly closing the connection. This caused goroutines to accumulate — observed as 55,000+ stuck goroutines in production.

The fix added an idleTimeoutConn wrapper that resets a per-operation deadline on each Read/Write. If no data flows for 5 minutes, the deadline fires, io.Copy returns an error, CopyReadWriteCloser closes both streams, and the goroutine exits. The timeout resets on each successful read/write, so active streams are unaffected — only truly idle/dead streams are cleaned up.

Skywire Development Update — April 6, 2026

Mon, 06 Apr 2026 00:00:00 +0000

Skywire: Setup-Node Goroutine Leak Fix

Route setup-node goroutine leak (#2280) — a serious production issue: the setup-node was accumulating 500+ leaked goroutines within minutes of restart.

Root cause — MakeMap used an unbuffered results channel, causing goroutines to block forever on send when the reader stopped after the first error. Combined with no dial timeout, unreachable visors caused indefinite blocking in DialStream.readResponse.

The fix — added buffered channels and explicit dial/handler timeouts so stuck dials can’t accumulate. The setup-node now cleanly errors out and cleans up goroutines when it can’t reach a visor.

Skywire Development Update — April 4, 2026

Sat, 04 Apr 2026 00:00:00 +0000

Skywire: Regional Saturation Scaling for Rewards

A significant economic change to the reward system: regional saturation scaling (#2278).

The problem — the presence pool distributes rewards equally across all uptime-eligible visors. If a single country has 1,000 visors, it receives 1,000 shares. This creates an incentive to flood a single region with cheap VPS instances to maximize reward extraction, which distorts the geographic distribution of the network.

The fix — apply diminishing returns to the presence pool based on unique IP addresses per country. Countries with more unique IPs still receive a larger total allocation, but each additional IP contributes less. Default is square-root scaling (configurable via --sat-exp flag). A country with 100 IPs gets sqrt(100) = 10 units of weight per IP instead of 1 per IP; a country with 4 IPs gets sqrt(4) = 2 units per IP — so the 100-IP country gets 5× the weight of the 4-IP country, not 25×.

Skywire Development Update — April 3, 2026

Fri, 03 Apr 2026 00:00:00 +0000

Skywire: SKYDEPLOY Override

New environment variable (#2276) — SKYDEPLOY=/path/to/config.json overrides the embedded services-config.json deployment configuration. This supports:

Private networks — point Skywire at a custom deployment without rebuilding
Corporate deployments — run a private Skywire network with your own TPD, DMSG, Address Resolver, etc.
Testing — quickly switch between test and production deployments

The embedded config is still used as the default, so nothing changes for users on the public network. But operators running private deployments no longer need to patch and rebuild Skywire to change the discovery URLs.

Skywire Development Update — April 2, 2026

Thu, 02 Apr 2026 00:00:00 +0000

Skywire: DMSG gRPC Listener

A new remote-management capability: DMSG gRPC listener for remote gotop and stats (#2271).

Design — a new DmsgGRPCPort (49) serves gRPC over DMSG alongside the existing local CLI gRPC. The DialDmsgRPC function was updated to dial the new port instead of DmsgHypervisorPort. This enables:

Remote gotop (system activity monitor) over DMSG
Stats streaming from any visor to any other visor
Ping and latency measurements between visors

Both visors need the update — the local visor dials the new port and the remote visor listens on it. Once deployed, operators can run skywire cli visor ping or stream system activity from any visor they have authorized access to, all over the encrypted DMSG overlay.