Transport Setup

Transport Setup

Portal dials each backend server over either RakNet or NetherNet, chosen independently per server (see the proxy's own Backend Transports page for how Portal itself handles this). This page covers the Dragonfly/PortalDF side specifically: getting Config.Transport and Config.ServerAddress right, and keeping them in sync with Dragonfly's own listener config — which is the single most common mistake when switching a server to NetherNet.

The two configs that must match, by hand

There are two separate things, and neither reads the other:

1. Dragonfly's own config.toml decides whether Dragonfly actually starts a NetherNet listener at all, and at what address.
2. PortalDF's Config.Transport / Config.ServerAddress decide what Portal is told to dial.

If they disagree — say, config.toml only starts a RakNet listener but PortalDF is told TransportNetherNet anyway — nothing errors at startup. Portal will simply try to reach an endpoint that isn't there, and its health check will silently mark this server unhealthy. From v0.0.8, PortalDF validates its own side (that Transport and ServerAddress are internally consistent) before ever connecting, so a malformed pair fails immediately and locally with a clear error — but it has no way to see into Dragonfly's config.toml, so the two still need to be kept consistent by hand.

Running RakNet (the default)

Nothing special — this is what DefaultConfig() already gives you. ServerAddress is a plain "host:port" pair, matching whatever Dragonfly's config.toml has under [Network] Address:

portaldf.Enable(srv, portaldf.Config{
	ProxyAddress:  "127.0.0.1",
	SocketPort:    19131,
	Secret:        "your-secret",
	ServerName:    "Hub1",
	ServerAddress: "127.0.0.1:19135", // matches Network.Address in config.toml, e.g. ":19135"
	Transport:     portaldf.TransportRakNet, // or omit — it's the default
})

Running NetherNet

Two changes from RakNet: Transport: portaldf.TransportNetherNet, and ServerAddress becomes a full URL (http:// or https://) instead of a bare host:port — the URL of Dragonfly's own NetherNet signaling endpoint.

Side-by-side example, one Dragonfly instance running NetherNet only:

config.toml (Dragonfly's own listener config — Address here is a bare host:port, never a URL):

[Network]
  Address = ":19135"
  Transport = ["nethernet"]      # or ["raknet"], or both: ["raknet", "nethernet"]
  [Network.NetherNet]
    Address = ""                 # "" reuses Network.Address (TCP; doesn't collide with RakNet's own UDP port)
    UDPPorts = "19137"           # the actual WebRTC media port — see "udp_ports collisions" below

main.go (PortalDF's config — ServerAddress here is a full URL):

portaldf.Enable(srv, portaldf.Config{
	ProxyAddress:  "127.0.0.1",
	SocketPort:    19131,
	Secret:        "your-secret",
	ServerName:    "Hub2",
	ServerAddress: "http://127.0.0.1:19135", // URL, matching Network(.NetherNet).Address above — not host:port
	Transport:     portaldf.TransportNetherNet,
})

Two different formats, describing the same one port. This mismatch — putting a URL where Dragonfly wants a bare address, or vice versa — is the single most common error when setting this up; if you see a ServerAddress is invalid error from Dragonfly itself, or a ServerAddress must be a URL-shaped error from PortalDF, check exactly this. See the proxy-side Troubleshooting page for the exact error text either mistake produces.

UDPPorts collisions

If this server runs NetherNet and it sits on the same physical host as either Portal itself (if Portal is also using NetherNet for its player listener) or another NetherNet backend server, each one needs its own distinct UDPPorts value in its respective config.toml. Two independent NetherNet listeners on one machine can't bind the same UDP port — whichever starts second fails outright, and if NetherNet was that server's only configured transport, Dragonfly logs no listeners could be created; the server is unreachable and the server ends up completely unreachable despite still running.

A safe pattern for local testing with everything on one machine: give Portal 19133, and increment from there for each NetherNet backend (19137, 19138, ...).

Mixing servers freely

Every Dragonfly instance behind the same proxy is configured independently — nothing here is proxy-wide. A RakNet-only server, a NetherNet-only server, and a dual-transport server (Transport = ["raknet", "nethernet"] in that server's own config.toml, though PortalDF itself still only tells Portal one transport to dial it over) can all sit behind one Portal instance at once. Portal learns each server's transport the moment it registers — there's no proxy-side config for this at all.