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
SocketCoreenum
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.
Top comments (0)