Jump to content

Recommended Posts

Posted

A2S Query Cacher

Documentatie: https://developer.valvesoftware.com/wiki/Server_queries

Discord modding: https://www.fairside.ro/modders/

Software complementar: A2S Query Tester

 

Compatibilitate A2S

  • A2S_INFO

  • A2S_PLAYER

  • A2S_RULES (indisponibil pe engine-ul de CS2 la momentul redactarii postarii pe forum)

 

Plus compatibilitate A2S_SERVERQUERY_GETCHALLENGE.

Poate fi extinsa compatibilitatea pentru a acoperi A2A_PING (deprecated for some games) in cazul in care e nevoie.

 

Raspunsuri A2S

Scopul acestui software este de a memora in cache raspunsurile la query-urile A2S pentru Source Engine si livrarea lor on-demand. Programul prezinta compatibilitate 100% cu engine-ul jocurilor CSGO si CS2, dar si cu alte jocuri de tip Source care utilizeaza A2S. De asemenea, software-ul trimite raspunsuri catre Steam server browser mai rapid decat engine-ul, contribuie la stabilitatea valorilor de latency si ajuta impotriva atacurilor VSE (DoS/DDoS). Dezvoltarea acestui program se bazeaza pe idei puse in practica in alte limbaje de programare (C, Java) de catre alti programatori care au lansat variante open-source. Cu toate ca nu ne-am inspirat din codul public al acestor variante (intrucat nu a fost nevoie), ele reprezinta un punct de referinta important pentru orice persoana care e interesata de dezvoltarea unui software similar.

 

Identificand probleme specifice in timpul atacurilor pentru software-ul open-source scris in Java si observand limitarile varientei open-source scrise in C (bazate pe Netfilter framework), am decis sa ne scriem propriul software in Go pe baza unui proof of concept realizat de noi si urcat pe GitHub in 2025. Intregul proces de development cu notele atasate in aceasta postare si alte modificari din backend garanteaza ca obtinem tot ce putem mai bun din limbajul de programare Go. Obtinerea performantei maxime din orice limbaj de programare e destul de dificila, in mod special in mediile high-concurrency unde conteaza balansarea dintre ciclurile CPU si alocarile de memorie, pe langa partea de code readability si maintainability.

 

Am incercat din rasputeri sa livram unele dintre cele mai bune rezultate cu un overhead mic pentru CPU si RAM in puncte cheie, in mod special in timpul evenimentelor de high-concurrency. Consider ca implementarea noastra din Go, cu schimbarile din versiunea 2.0.0, intrece orice alta solutie mainstream scrisa intr-un limbaj de programare mai îndepărtat de assembly precum Java si C#. Daca luam in calcul AOT (Ahead-of-time compilation), lucrurile pot fi diferite, desigur. Totusi, daca identificam nevoia de ceva mai mult, putem merge direct catre C, C++ sau Rust. Mentionez de asemenea faptul ca orice bottleneck regasit in acest software va fi tratat ASAP - asta in cazul in care ceva va fi gasit vreodata - avand in vedere strictetea de care am dat dovada in dezvoltarea acestui proiect de la inceput.

 

Am implementat de asemenea Round-Robin scheduling:

  • even load balancing across workers
  • lower lock contention on a shared channel
  • low latency under high packet rates

 

Important notes

Pentru packets/bytes counter ar trebui sa implementam atomicity with CAS sau mutual exclusion. Prin urmare, am renuntat la idee intrucat dorim ca software-ul final sa fie foarte performant in timpul procesarii de UDP packets. In loc sa aveti CPU overhead sau increased latency in acest software, puteti utiliza Linux Kernel statistics (sau alte implementari XDP/eBPF). Regasiti informatii mult mai clare si precise pentru network interfaces si UDP sockets (ex.: netstat, /proc/net/udp). Monitorizati astfel sanatatea receptiei de UDP packets si pierderile.

 

Intrucat codul acestui software poate fi utilizat pentru a adauga servere false pe site-uri web care scaneaza jucatorii online si poate contribui la informatiile false din Steam master server - am decis ca acesta sa ramana privat. Evitam astfel plangeri, probleme si lupte intre comunitati din toata lumea care ar putea folosi programul cu intentii rele. Singurul impediment este dat de problemele intampinate de detinatorii de servere care trebuie sa mitigheze atacurile VSE (DoS/DDoS), insa sunt sigur ca vor gasi o solutie sa treaca peste.

 

Screenshots v1

A2S-Query-Cacher-v1.png

 

Screenshots v2

A2S-Query-Cacher-v2.png

 

Development progress notes

v1.0.0

  • Integrate the fastest logging library from Go ecosystem (mostly zero memory allocs)
  • Integrate logging file handler with MaxSize, MaxBackups, MaxAge, Compression
  • Customize the logging library and change order of types for console logging
  • Integrate POC A2S handler from other libraries to do some testing
  • Pass raw bytes with our own funcs for more testing
  • Write our own config file handler with error handling in mind and good bounds
  • Write our own listener, emitter and types with performance in mind
  • Write our own A2S query handler with challenge support
  • Write our own failsafe for A2S client responses before passing raw bytes
  • Write our own logging control mechanism for each A2S type
  • Decrease memory allocs during runtime concurrency
  • Decrease CPU cycles during runtime concurrency
  • Final optimizations before finishing
  • Pass the final test series with ease

 

v2.0.0

  • Use pointers for A2S types
  • Use buffer pool for UDP queries
  • Use packet pool for A2S DATA reuse
  • Improve other algorithms
  • Improve channels management
  • Implement channel sharding (beside queue for each worker)
  • Use round-robin for channel sharding
  • Have CPU threads number as embedded (const) for GOMAXPROCS
  • Have workers number as embedded (const) for better arrays performance
  • Decrease CPU cycles and memory allocations even more
  • Have runtime stack allocs instead of heap allocs where possible
  • Employ other micro-optimization techniques

 

Future versions

Este posibil ca viitoarele versiuni ale software-ului scris in Go sa includa caracteristicile listate mai jos.

Totusi, asa cum am spus la inceput: daca identificam nevoia de ceva mai mult, putem merge direct catre C, C++ sau Rust.

Totul depinde de nevoile comunitatii in raport cu contextul in care ne aflam.

  • FEATURE: Use ReadBatch to reduce system calls
  • FEATURE: Enable socket-level optimizations (via syscall.RawConn)
  • FEATURE: Use SO_REUSEPORT, SO_RCVBUF/SO_SNDBUF or even IP_PKTINFO
  • FEATURE: Use epoll via raw syscalls or third-party
  • FEATURE: Lower-level networking and linux-specific tricks
  • Love 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...