Encrypted sessions
Key exchange establishes directional session keys. Application data passes through authenticated encryption before it reaches the underlying transport.
THE PROTOCOL
A small transport layer.
A practical integration boundary.
STCP is developed by Paxsudos IT in Finland for applications that need secure data exchange while keeping transport overhead visible and controllable. Its design follows two rules: every bit on the wire costs, and keep the implementation simple.
Compact framing
The supplied implementation uses a 17-byte STCP header for packet type, flags, payload length, sequence, acknowledgement and connection identification.
This is the STCP header, not the total encrypted packet or IP/link overhead.
Application control
Socket integration gives applications a familiar connection and send/receive model. Compression can be disabled, selected automatically, or configured explicitly.
SYSTEM DESIGN
One core. Platform-specific integration.
The application interface, protocol logic and network carrier have separate responsibilities. Linux and Zephyr connect the shared protocol core to their own socket, scheduling, memory and cryptographic facilities.
Application boundary
Linux exposes an STCP socket family through kernel socket operations. A socket-based SDK can remain independent of kernel module source code. Zephyr provides its own platform and socket integration.
Protocol core
Session logic coordinates connect, listen, accept, send, receive and shutdown. Separate modules handle wire encoding, cryptography, compression, connection state and carrier queues.
Carrier and network
STCP-TCP and STCP-UDP carry protocol frames over TCP or UDP. Ethernet, LTE and satellite are network paths beneath those carriers; selecting a benchmark label does not configure that path.
DATA PATH
Session keys to protected payloads.
1. Establish a session
The implementation uses X25519 shared-secret exchange and key derivation to produce separate transmit and receive keys.
2. Encode and protect
The sender optionally compresses the payload, then uses AES-256-GCM authenticated encryption. STCP carries the framing and session information needed by the receiver.
3. Validate and deliver
The receive path handles session and sequence state, verifies encrypted data, decompresses when indicated, and delivers application bytes through the socket interface.
Encryption is one part of a deployment's security model. Peer identity, trust provisioning and application authorization must be defined for the actual installation. The presence of X25519 and AES-GCM alone is not a claim of certificate-based peer authentication or an independent security audit.
ADAPT TO THE PAYLOAD
Compress when it helps.
Text, telemetry and repetitive messages can offer opportunities to reduce payload volume. Already compressed or high-entropy data may offer little benefit. STCP keeps compression under application control.
OFF
Send without payload compression while retaining STCP's protected data path.
AUTO
Use the automatic compression path and its fallback behavior rather than forcing every payload to compress.
Levels 1–5
Select an explicit compression level and evaluate the balance between transmitted bytes and CPU cost using the same input corpus.
Payload reduction does not directly establish complete link savings, higher throughput or lower energy consumption. Those outcomes depend on framing, the network, processing cost and device behavior.
WHERE IT FITS
From Linux hosts to embedded links.
Linux
Kernel integration combines C socket wrappers with Rust protocol logic. Linux-to-Linux and Linux-to-Raspberry Pi setups provide practical interoperability and regression targets.
Zephyr / nRF9151
The embedded integration supports separate Ethernet and LTE build configurations. W5500 supplies the Ethernet path; LTE uses the modem's network facilities.
Embedded applications ↗IoT and constrained links
Short connections, small messages and limited data allowances make connection overhead and bytes per useful message worth measuring. Satellite/NTN testing requires compatible hardware, an enabled service and confirmed coverage.
EVIDENCE, WITH CONTEXT
Inspect the measurements.
Benchmark pages keep the detailed tables separate from this overview. Read throughput alongside connection setup, transmitted bytes, CPU time per useful data volume and the recorded test conditions.
Linux corpus & resources
Browse connection categories and their archived runs, including raw data and resource measurements.
Platform benchmark archives ↗Zephyr transport matrix
Inspect embedded upload, download and bidirectional measurements by Ethernet, LTE or satellite category.
Zephyr benchmarks ↗Detailed lab report
View the existing generated regression, benchmark and compression report with its own verification scope.
Lab report & compression tables ↗Results describe the displayed environment. Missing LTE or satellite measurements are not inferred from Ethernet tests. Benchmark validation and Robot regression results are reported separately.
BUILD AND EVALUATE
Start with your application and network.
Choose Linux or Zephyr, establish a working IP path, then bring up the STCP peer and application socket interface. Verify an uncompressed exchange first, compare AUTO and explicit levels with representative payloads, and retain the raw benchmark data with the platform configuration.
STCP's value depends on the workload: connection frequency, payload compressibility, device resources and network constraints. Evaluate those together rather than treating a single throughput figure as the entire result.