Update README.md

This commit is contained in:
Alexey
2025-12-30 22:18:22 +03:00
committed by GitHub
parent dd6badd786
commit 2c2ceeaf54

View File

@@ -1,7 +1,6 @@
# Telemt - MTProxy on Rust + Tokio # Telemt - MTProxy on Rust + Tokio
**Telemt** is a fast, secure, and feature-rich server written in Rust **Telemt** is a fast, secure, and feature-rich server written in Rust: it fully implements the official Telegram proxy algo and adds many production-ready improvements such as connection pooling, replay protection, detailed statistics, masking from "prying" eyes
It fully implements the official Telegram proxy algo and adds many production-ready improvements such as connection pooling, replay protection, detailed statistics, masking from "prying" eyes
# GOTO # GOTO
- [Features](#features) - [Features](#features)
@@ -9,6 +8,7 @@ It fully implements the official Telegram proxy algo and adds many production-re
- [Build](#build) - [Build](#build)
- [How to use?](#how-to-use) - [How to use?](#how-to-use)
- [Systemd Method](#telemt-via-systemd) - [Systemd Method](#telemt-via-systemd)
- [Why Rust?](#why-rust)
## Features ## Features
@@ -61,3 +61,26 @@ WantedBy=multi-user.target
3. In Shell type `systemctl start telemt` - it must start with zero exit-code 3. In Shell type `systemctl start telemt` - it must start with zero exit-code
4. In Shell type `systemctl status telemt` - there you can reach info about current MTProxy status 4. In Shell type `systemctl status telemt` - there you can reach info about current MTProxy status
5. In Shell type `systemctl enable telemt` - then telemt will start with system startup, after the network is up 5. In Shell type `systemctl enable telemt` - then telemt will start with system startup, after the network is up
## Why Rust?
- Long-running reliability and idempotent behavior
- Rusts deterministic resource management - RAII
- No garbage collector
- Memory safety and reduced attack surface
- Tokio's asynchronous architecture
## Roadmap
- Zero-copy, minimal allocs on hotpath
- Config Reload-on-fly
- No global mutable state
- Fail-fast on start + Fail-soft on runtime (only WARN/ERROR)
- Client isolation
- Backpressure-aware IO
- "Secret Policy" - SNI / Secret Routing :D
- Adtag Support per SNI / Secret
- DC Healthchecks + global fallback
- Multi-upstream Balancer and Failover
- Bind to device or IP for outbound/inbound connections
- Strict FSM per handshake
- Session-based Antireplay with Sliding window, non-broking reconnects
- Web Control: statistic, state of health, latency, client experience...