SankuGrid

This is a small project I built to test an idea - what if the idle computers on your home or office network could just find each other and share compute power, without any setup. No config files, no typing IP addresses, no login. You run it on two machines on the same wifi and they find each other in a couple seconds.

Built in Rust with tokio and GTK4. I made sure it stays light because I'm testing it on an old-ish dual core i3 with only 4GB RAM, not some fancy dev machine.

Made by Tharindu Liyanage Sanku

What it does right now

• Machines on the same network find each other automatically using UDP broadcast. No mDNS, nothing fancy.
• Every machine tells the others its hostname, OS, number of cores and free RAM.
• There is a "Compute Power Pool" screen that just adds all this up - total nodes, total cores, total free RAM in the whole group.
• One machine can send a piece of work to another over TCP and get the answer back. Right now the "work" is just calculating a SHA-256 hash of some bytes. It's not meant to be useful on its own, it's there to prove the pipe works - split the work, send it, get it computed somewhere else, bring it back. Later this can become file compression, image processing, whatever.
• There's a normal GUI (GTK4) and also a headless version (daemon) that you can run on a machine with no screen, as a background service.

Why I built it this way

UDP broadcast, not mDNS. mDNS is probably the "correct" way to do this long term and it works better across multiple subnets, but it's heavier to set up and honestly a bit flaky depending on router and driver. For a single home network, plain broadcast just works, no extra dependencies needed. I kept the discovery code separate so mDNS can be swapped in later without touching anything else.

TCP for sending the actual work. The discovery messages are tiny and it's fine if one gets lost. But actual task data can be big and has to arrive complete, so that part goes over TCP instead, straight to the other machine's worker port. Since TCP doesn't know where one message ends and another begins, I just send a 4 byte length first, then the actual data.

Why Rust and GTK4 and not something else. No garbage collector randomly pausing things while the user is trying to use their computer for something else. tokio runs everything - discovery, the worker, all of it - as small async tasks on a few threads instead of spinning up a thread for every little thing. The GUI uses the GTK4 that's already installed on the system instead of bundling its own browser like Electron apps do, so it doesn't eat up a ton of extra memory just to show a window.

A bug I actually ran into

In my first version of the discovery code, I was accidentally binding the same UDP port twice - once to broadcast, once to listen. The second bind failed, but because that failure happened inside a spawned task that nobody was checking, the error just got swallowed silently. So the app looked totally fine, it kept sending broadcasts, never crashed, but it could never actually hear anything back from other machines. I only caught this by running two instances at once and noticing neither saw the other. Fixed it by binding the socket just once, sharing it between the two tasks, and turning on SO_REUSEADDR/SO_REUSEPORT so you can even run the daemon and the GUI on the same machine at the same time without them fighting over the port.

Security - be honest about this

Right now, whatever gets sent to a machine's worker port just gets run, no checking who sent it. That's fine for testing on your own network at home, but don't put this on a network you don't fully trust yet. If this ever goes further, it needs:

1. Some kind of pairing step, so a machine only accepts work from other machines you've actually approved - kind of like pairing a Bluetooth device.
2. A fixed list of allowed task types instead of accepting anything. Never just "run this code."
3. A limit on how much CPU, RAM and time a machine will give to someone else's task, so it can't accidentally choke the host's own work.
4. Encrypting the connection, mainly so someone else on the same wifi can't just read the data going back and forth. Nice to have but not urgent for a LAN-only tool.

I left all of this out on purpose for now, just to keep the first version simple enough to actually understand end to end.

What I actually tested

Everything below actually happened, I didn't just assume it would work:

• cargo build --workspace builds everything - core, daemon, and the real GTK4 GUI - clean, no warnings.
• Ran two daemons on the same network. They found each other and showed the right hostname, OS, cores and RAM for each.
• Checked the Compute Power Pool with those two running - it correctly added up to 2 nodes, 2 cores, and the right combined RAM.
• Sent a chunk of bytes over a real TCP connection to a running daemon and got back a SHA-256 hash. Compared it to hashing the same bytes locally - matched exactly.
• The double-bind bug above - found it, fixed it, tested it again to make sure it was actually gone.

What I haven't checked yet: how the actual GTK4 window looks. The build environment I used has no screen attached, so I can only confirm the GUI code compiles fine against gtk4-rs. You'll need to build it yourself and just look at it to be sure it renders properly.

How to build it on Linux

First, install what you need

Arch Linux

sudo pacman -S --needed base-devel gtk4 pkgconf rustup
rustup default stable

Ubuntu / Debian / Pop!_OS

sudo apt update
sudo apt install -y build-essential libgtk-4-dev pkg-config curl
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"

Then build it

git clone https://github.com/xnodesdevelopers/sankugrid
cd sankugrid
cargo build --release --workspace

Use the release build, it's what you actually want to run day to day, especially on lighter hardware. You'll find the binaries in target/release/:

• sankugrid-daemon - runs in the background, no window
• sankugrid-gui - the actual dashboard

Running it

# on this machine
./target/release/sankugrid-gui

# on any other Linux machine on the same network
./target/release/sankugrid-daemon

Give it a few seconds, they'll find each other. That's it, nothing else to set up.

Screenshots

Installing

Rust Compiling

The peer list

Running it as a background service (no GUI machine)

If you want some machine to just sit there and quietly donate spare compute without needing a screen or a login session:

sudo cp target/release/sankugrid-daemon /usr/local/bin/
sudo cp packaging/sankugrid-daemon.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now sankugrid-daemon
sudo systemctl status sankugrid-daemon
journalctl -u sankugrid-daemon -f