Download the Redstone online server kernel suitable for your server.
Server kernel downloads
| Platform | Kernel download | Size |
|---|---|---|
| Windows windows-amd64 | hongshis-windows-amd64.exeDownload | — |
| Linux linux-amd64 | hongshis-linux-amd64Download | — |
| Linux linux-arm64 | hongshis-linux-arm64Download | — |
Usage Guide
- Get a machine with a public IP. Players connect to it directly, so it has to be reachable from outside.
- Write a config.
./hongshis --print-config > config.jsonprints a complete template; keep only the fields you want to change. - Open three ports.
8080/tcp,8000/tcpand the tunnel range. Both the cloud security group and the host firewall. - Run it, and keep it running. Hand it to systemd or another supervisor so it comes back after a reboot.
# built-in defaults, no config file at all
./hongshis
# or: write a template once, edit only what you need
./hongshis --print-config > config.json
./hongshis --config config.jsonPrecedence runs low to high: built-in defaults, then config.json, then command-line flags. A misspelled field name is a hard error that lists every valid field, so it never silently falls back.
| Port | Protocol | Who connects |
|---|---|---|
| 8080 | TCP | Control plane. The kernel connects here to claim a tunnel. |
| 8000 | TCP | Data plane. The kernel connects here to open the byte pipe. |
| 20000-60000 | TCP | Tunnel ports. Players connect here; the range is configurable. |
If you move control_port or data_port, everyone running the kernel has to point at the same numbers with --control-port and --data-port. Open the new ports too, or the kernel connects and no player can follow.
The three defaults that decide when a tunnel disappears
| Field | Default | Meaning |
|---|---|---|
| --tunnel-idle-secs | 600 | Reclaim a tunnel after this long with no players. 0 keeps it forever. |
| --pipe-idle-secs | 120 | Drop a data pipe after this long with no bytes moving. 0 never checks. |
| --pairing-secs | 10 | How long a player waits for the host side to open its pipe. |
Exit codes: 0 for a normal exit, 1 for a runtime failure such as a port already in use, 2 for a bad config or a bad flag. When a tunnel is reclaimed the kernel's control connection drops and the kernel process exits on its own.
Deploy a public node
Most people who want one evening of multiplayer do not own a machine with a public IP. A listed node is what makes download the kernel, open a room possible without one: the kernel picks an available relay, and the player never has to know who is moving the bytes.
What a listed node has to have
- Be inside mainland China. Game traffic must never leave the mainland, so a node outside it is not eligible at all — a fast machine in the wrong place is worse than a slow one in the right one. This is the one requirement that cannot be traded against the others.
- A public IP. Players connect straight to this machine, so it has to be reachable from outside.
- The public default ports, 8080 and 8000. Keeping the defaults is what lets the kernel connect with no extra flags on anybody's side.
- A range of forwarding ports open. The tunnel ports players land on, in addition to the two above.
- 30 Mbps or better. Every session shares one uplink, so this is the number that decides how many rooms stay smooth at once.
- CPU and memory are not the constraint. The relay only moves bytes, so it is not doing the work the game does.
- Run it under a supervisor. Something that restarts it if it dies, rather than a terminal window you keep open.
- Start on boot. A node that vanishes when the machine reboots is worse than no node at all.
You never see anyone's game. A relay moves bytes and nothing else; HTTP/HTTPS filtering happens on the kernel side. Listing a node does not give you access to other people's worlds.