DEV Community: Nytrox

I built a TCP networking library in Python at 14 : and v1.6.2 just hit 110k msg/s with zero dependencies

Nytrox — Sun, 12 Apr 2026 12:54:05 +0000

I'm 14 years old and I've been working on an open-source Python library called Veltix for the past few months. I just released v1.6.2 and the benchmarks genuinely shocked me, so I wanted to write up what changed and why.

Before I get into the numbers: the code is entirely mine. The README, comments, and changelog were written with AI assistance for grammar and formatting, and so was this article since English isn't my first language. I want to be transparent about that upfront.

What is Veltix?

Veltix is a TCP networking library for Python. It gives you structured client/server communication without having to manage framing, threading, handshake, or protocol design yourself, and without any external dependencies.

It sits between raw sockets (which give you nothing) and heavier frameworks like Twisted (which give you everything but at a steep cost in complexity). The target is developers who want something that just works, is easy to read, and doesn't pull in half of PyPI.

Here is what a basic echo server looks like:

from veltix import Server, ClientInfo, ServerConfig, Response, MessageType, Request, Events

CHAT = MessageType(code=200, name="chat")
server = Server(ServerConfig(host="0.0.0.0", port=8080))
sender = server.get_sender()

def on_message(client: ClientInfo, response: Response):
    reply = Request(CHAT, f"Echo: {response.content.decode()}".encode())
    sender.broadcast(reply, server.get_all_clients_sockets())

server.set_callback(Events.ON_RECV, on_message)
server.start()

No event loop, no async/await, no dependencies. Just stdlib.

What changed in v1.6.2?

The biggest change is a protocol optimization that I honestly did not expect to have this much impact.

Previously, every message carried a 62-byte header. The request ID was a UUID string, and payload integrity was verified with SHA-256. In v1.6.2:

The header is now 22 bytes
Request IDs are 4 raw bytes instead of a UUID string
SHA-256 is replaced by CRC32 for payload integrity

Less data per message, much lighter hashing. That's it. The result:

Burst throughput:   55,606 msg/s  ->  110,011 msg/s  (+98%)
Memory per client:      78 KB     ->       64.4 KB    (-17%)
Average latency:     0.011 ms     ->      0.007 ms    (-36%)
Concurrent stress:  33,482 msg/s  ->     39,123 msg/s (+17%)

All of this is still pure Python, threading + blocking sockets, no C extensions, no event loop. The minimum supported Python version is 3.8+, which also means Windows 7 compatibility.

Why not asyncio?

Honestly, the main reason was learning. I wanted to understand what happens at the socket level before adding an event loop abstraction on top. Selectors and threading forced me to think about framing, concurrency, and state management in a way that asyncio would have hidden from me.

That said, asyncio is next. v1.7.0 will introduce a selectors-based event loop as an optional backend. The API stays exactly the same, you just switch to SocketCore.ASYNC. No migration needed.

What is in the library?

Beyond basic send/receive, Veltix includes:

Automatic HELLO/HELLO_ACK handshake with version compatibility check
Request/response correlation with send_and_wait() and configurable timeout
Decorator-based message routing with @server.route(MY_TYPE)
Auto-reconnect with configurable retry and disconnect state callbacks
Built-in ping/pong with latency measurement
Thread-safe, colorized, file-rotating logger
Client tags for attaching metadata to connections
Performance mode presets (LOW, BALANCED, HIGH)
Swappable socket backend via SocketCore enum

What is next?

v1.7.0 brings the selectors-based event loop. After that I want to experiment with a Rust core via PyO3, published as a completely optional experimental backend. And more protocol optimizations are in the pipeline.

I have no idea how far this project will go, but building it has taught me more about networking, Python internals, and protocol design than anything else I have done so far.

If you want to try it:

pip install veltix

GitHub: https://github.com/NytroxDev/Veltix
PyPI: https://pypi.org/project/veltix/1.6.2/
Docs: https://nytroxdev.github.io/Veltix/

Happy to answer questions about any of the internals or design decisions.

Veltix v1.6.2: Lighter protocol, better architecture, and Rust experiments ahead

Nytrox — Wed, 18 Mar 2026 22:23:41 +0000

Veltix v1.6.2: Lighter, Faster, and a Rust Experiment Coming

Hey Dev.to!

I'm Nytrox, a self-taught developer and the creator of Veltix, a pure Python TCP networking library with zero dependencies. Today I want to share what's coming in v1.6.2 and where the project is heading.

What changed in v1.6.2

Reworked socket abstraction layer

The biggest architectural change in this version is a complete rework of BaseSocket and ThreadingSocket. The new BaseSocket is a clean, minimal Protocol that exposes only what matters: bind, connect, send, close, and callbacks. All the threading logic now lives inside ThreadingSocket instead of leaking into Server and Client. This makes the codebase much easier to maintain and paves the way for a selectors-based backend in v1.7.0.

Lighter protocol header

The message header went from 62 bytes down to 22 bytes. I replaced SHA256 with CRC32 and dropped UUID4 in favor of a 4-byte random ID. On high throughput workloads this makes a real difference.

MessageBuffer optimization

The internal message buffer was reworked to eliminate unnecessary memory allocations on every received message. Less garbage collection pressure, better throughput.

What's next: experimenting with Rust

In the coming versions I'm planning to experiment with rewriting some performance-critical parts of Veltix in Rust via PyO3. This will be completely optional for users who don't want the compiled extension. Pure Python will always remain the default.

A project built on top of Veltix

I'm also working on a real-world project powered by Veltix to prove it's production-ready. More details soon.

Veltix is at 3,150+ downloads and growing. If you're curious, check it out on GitHub or PyPI!

GitHub: github.com/NytroxDev/veltix

Veltix v1.5.0 — Routing & Auto-Reconnect

Nytrox — Sun, 08 Mar 2026 23:13:37 +0000

Veltix v1.5.0 is out! This release brings two major features: decorator-based message routing and automatic reconnection.

Message Routing

Instead of a single global on_recv callback, you can now handle each message type with a dedicated handler:

CHAT = MessageType(code=200, name="chat")
STATUS = MessageType(code=201, name="status")

@server.route(CHAT)
def on_chat(response, client):
    print(f"[{client.addr[0]}] {response.content.decode()}")

@server.route(STATUS)
def on_status(response, client):
    print(f"Status: {response.content.decode()}")

Same thing on the client side:

@client.route(CHAT)
def on_chat(response, client=None):
    print(f"Server: {response.content.decode()}")

Routes take priority over on_recv and run in the thread pool — slow handlers never block message reception.

Auto-Reconnect

Set retry in ClientConfig and Veltix handles the rest:

client = Client(ClientConfig(
    server_addr="127.0.0.1",
    port=8080,
    retry=5,
    retry_delay=1.0,
))

def on_disconnect(state: DisconnectState):
    if state.permanent:
        print(f"Disconnected — {state.reason.name}")
    else:
        print(f"Retrying... {state.attempt}/{state.retry_max}")

client.set_callback(Events.ON_DISCONNECT, on_disconnect)

You can also cancel or force retries at any time:

client.stop_retry()   # cancel pending retries
client.retry(max=10)  # force a new attempt

Other improvements

PerformanceMode — LOW / BALANCED / HIGH presets to tune socket timeout and CPU usage
BufferSize — SMALL / MEDIUM / LARGE / HUGE presets for common buffer sizes

Breaking change

on_disconnect on the client now receives a DisconnectState argument:

# Before
client.set_callback(Events.ON_DISCONNECT, lambda: ...)

# After
client.set_callback(Events.ON_DISCONNECT, lambda state: ...)

📦 pip install veltix
📖 Documentation
⭐ GitHub

I built a Python library to make TCP networking as simple as Fastapi

Nytrox — Thu, 05 Mar 2026 23:37:33 +0000

TCP networking in Python is painful. You deal with raw sockets, manual buffering, thread management, message framing... it's a lot just to send a message between two programs.

So I built Veltix — an open-source Python library that makes real-time TCP networking simple and intuitive.

What does it look like?

Server:

from veltix import Server, ServerConfig, Events, MessageType

MSG = MessageType(code=300, name="chat")

server = Server(ServerConfig(host="0.0.0.0", port=8080))

def on_message(client, response):
    print(f"Received: {response.content.decode()}")

server.set_callback(Events.ON_RECV, on_message)
server.start()

Client:

from veltix import Client, ClientConfig, Request, MessageType

MSG = MessageType(code=300, name="chat")

client = Client(ClientConfig(server_addr="127.0.0.1", port=8080))
client.connect()
client.get_sender().send(Request(MSG, b"Hello Server!"))

That's it. No raw sockets, no manual buffering, no thread management.

What does Veltix handle for you?

TCP stream fragmentation — messages are always received complete, even if split across multiple packets
Message integrity — every message is SHA-256 hashed and verified automatically
PING/PONG — built-in latency measurement
send_and_wait() — send a request and block until you get the matching response, like an HTTP request
Broadcasting — send to all connected clients in one call
Thread-safe callbacks — your on_recv runs in a thread pool, so slow callbacks never block message reception

Why I built it

I wanted to build real-time applications in Python without writing the same boilerplate networking code every time. Libraries like asyncio are powerful but have a steep learning curve. I wanted something that felt as simple as FastAPI but for persistent TCP connections.

Performance

Benchmarked on Python 3.14, Linux:

Average latency: 0.012ms
Throughput: 67,000+ msg/s burst
64 players @ 64 tick/s: 100% message delivery

Current status

Veltix is at v1.3.0 with 2000+ downloads in 2 months. It's stable, tested, and ready to use.

What's next?

v1.4.0 — HELLO/HELLO_ACK handshake + thread pool for callbacks (coming soon)
v1.5.0 — decorator-based message routing (@server.route(MY_TYPE))
v1.6.0 — plugin system