Add architecture comparison document (ARCHITECTURE.md)

[Copilot]

Compares architecture, performance, safety, and language trade-offs across the four main MTProxy implementations (original C, this fork, mtg/Go, telemt/Rust). Recommends a winning architecture direction.

ARCHITECTURE.md

• Architecture overview of each project: this fork's epoll + static pools + zero-copy buffers, mtg's goroutine-per-connection, telemt's async Tokio tasks
• Language analysis (C vs Go vs Rust): runtime overhead, memory safety, tail latency, concurrency model
• Performance comparison: per-connection footprint (80B vs 4KB vs 256B), GC impact on p99, scalability to 100K connections
• Safety comparison: memory safety guarantees, anti-replay strength, fuzz/E2E/static-analysis coverage across projects
• Winning architecture: Rust + Tokio + io_uring for new builds; pragmatic recommendation to continue hardening the C codebase via its CI pipeline (ASan, libFuzzer, CodeQL, Telethon E2E) until a rewrite is justified
• Summary table: winner per dimension — raw perf → C, memory safety → Rust, test rigour → this fork, DPI resistance → this fork, deployment simplicity → Go

README.md

• Links to ARCHITECTURE.md from the existing "How This Fork Compares" section

.gitignore

• Adds !ARCHITECTURE.md exception (existing rule excludes *.md except shipped docs)

Original prompt

Compare architecture design with other competing projects. Performance wise and safety. Which language choice is best? Which architecture is best if none of these projects? Suggest winning architecture - language and internal design etc.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[dvershinin]

@copilot how to address "Single-threaded per worker — cannot utilise multiple cores within one process without forking." In existing codebase? Or it can be considered not a weakness ?

[Copilot]

@copilot how to address "Single-threaded per worker — cannot utilise multiple cores within one process without forking." In existing codebase? Or it can be considered not a weakness ?

It's not a weakness — it's the same proven architecture used by nginx and HAProxy. For an I/O-bound proxy workload, single-threaded epoll loops with fork()-based workers is actually the optimal design: each worker has independent connection pools with zero lock contention, and OS-level process isolation prevents cascading failures. The engine also has an internal job-thread system (jobs/jobs.c with pthread_create) that can offload CPU-bound work when needed.

Moved it from "Weaknesses" to "Strengths" with this context in e64177e.