STCPv3 is now READY!

🛰️ STCPv3 is being built satellite-first.

Satellite communication makes one design constraint impossible to ignore:

Every bit on the wire costs.

Bandwidth is limited. Airtime matters. Radio transmission consumes energy. On constrained and long-distance links, protocol overhead that looks insignificant on Ethernet can become something worth eliminating.

That principle has become a major design driver for STCPv3:

Transmit as little as possible while keeping the protocol useful.

STCPv3 already uses a compact 17-byte wire header. Now v3 adds another tool specifically suited to constrained links: optional automatic payload compression.

Compression is controlled per socket. An application can enable or disable it and define a payload-size threshold for when compression should be attempted.

And there is an important rule:

If compression does not make the payload smaller, STCP sends the original payload instead.

In other words, compression is there to save bytes — not simply to say that compression is enabled.

The first full compression interoperability tests are now passing across Linux and Raspberry Pi with both STCP-TCP and STCP-UDP.

The latest test run produced:

16 / 16 payloads compressed successfully
98,816 bytes → 1,156 bytes
97,660 bytes avoided on the wire
98.83% payload reduction
0 compression errors
0 decompression errors

The payload in this functional test is intentionally highly compressible. 98.83% is therefore not a claim about the compression ratio of arbitrary real-world traffic. Real-world savings depend entirely on the data being transmitted.

What the test demonstrates is that STCPv3 can automatically compress suitable payloads, transport them and reconstruct the original data correctly end-to-end.

And the complete STCPv3 regression suite remains green:

Linux / Raspberry Pi ✅
Zephyr / nRF9151 ✅
CoAP ✅
MQTT ✅
P2P 3-node ✅

Next comes benchmarking with different payload types and frame sizes to quantify the benefit under more realistic traffic patterns.

The direction for STCPv3 is very clear:

Satellite-first networking.

17-byte wire header.
Optional automatic payload compression.
Compression only when it saves bytes.
Linux, Raspberry Pi and embedded Zephyr targets.
CoAP, MQTT and P2P interoperability.

For terrestrial broadband, a few unnecessary bytes may not matter much.

On a satellite link, I want STCP to treat every one of them as something worth avoiding. 🛰️

#STCP #STCPv3 #Satellite #SatelliteIoT #IoT #EmbeddedSystems #Networking #Rust #Zephyr #nRF9151 #LowPower #Compression

STCPv3 näkee kohta päivänvalon!

STCPv3 osaapi automaattisesti pakata lähetettävän datan, jos käyttäjä haluaa. Erittäin hyvä esim IoT-laitteisiin jotka pelaavat radioaalloilla => bytejä aina menee optimi määrä, jos lähtevä data on pakattuna isompi, niin orggis lähetetään, jos ei, niin lähetetään pakattu data.

Vastaanottopuoli purkaa tavaran, ennenkuin ojentaa sitä loppukäyttäjälle. Eli pakkaaminen/purkaminen toimii ’piilossa’ käyttäjältä kokonaan.

Ihan tein satelliitit mielessä ja IoT-laitteet, varsinkin joissa energian käyttö pitää optimoida pieneksi.

Tuossa STCPv3:ssa on vaivaton tapa optimoida todella tiukaksi paketti + tarjoaa AES 256 bit salauksen silti..

Mietin tässä josko muuttaisi elinkustannusten takia Viron tai Saksaan.

Saksa ois jo tuttukin, kun siellä olen yhteenväliin noin 6kk asustellut. Viron hintataso tosin houkuttelee.. ja se, että Virosta Suomessa voisi paljon helpommin piipahtaa.

Otan tässä selvää, miten voisin yritykseni pitää silti kirjoilla Suomessa, eli ajatus olisi pitää yritykseni Suomessa kirjoilla.

Nyt lähitulevaisuus ratkaisee tuon, minne tästä repäsee ja lähtee maailmalle.

Pitää vertailla ja selvitellä tarkkaan miten homman toteuttasi. Olen ajatellut, että seuraavan kerran kun pyöreitä täytän, niin repästä kunnolla ja liikahtaa jonnekkin.

Olen silti ajatellut ihan Euroopassa pysyä..