FastCGI Server + Epoll for high performance CDN

Hi, to improve the service into Confiared I’m rewritting the CDN software.

We was with Nginx + Nginx FastCGI cache + PHP (to just proxy the reply). This solution lack fine cache control tuning, some bug due to Nginx cache.

Then I have rewritten the CDN as standalone FastCGI server, the cache is directly controlled by the server. If same url is already downloading, then the content is send from the partial downloaded content. I choose monothread to have great performance without thread coherency code (more simple to dev, more eficience if the code is very fast because if the code is very fast most of the time is consumed into thread management and data migration from a CPU to another CPU).

The code is specific, not flexible and generalist. I parse the protocols (DNS, FastCGI, …) on fly. That’s greatly improve the performance, reduce the memory. An internal page is served 3x more faster than a simple « Hello world » into PHP 7.4.

The future improvement are: better cache, cache some stuff where needed (DNS, …), use io_uring to improve file access and be 3x more fast than Nginx with static file, do profile to optimize the code. (And maybe do my own http server)

Benchmark for CatchChallenger cache

I have finish implement cache into HPS to reduce memory at server startup and startup time for server and client (usefull for phone or where the CPU is slow)

EDIT: How do the cache sync with datapack:

  • Scan at startup the datapack, create checksum, if checksum match the cache then load the cache. Problem: it’s slow mostly on slow disk and FS because need access to all inode, can greatly slow down the cache
  • Never check the datapack change, regen the cache manually. More performance, but not adapted to everyone. Need be intergrate where you update your datapack
CatchChallenger binary datapack size (datpack file cache * is not used if http mirror enabled), map can be stored into quadtree to improve the sapce used at exchange of more cache miss
The datapack load time is better, but can be improved even more
Memory is few bit better, but can be optimized

Why?

  • Load single file, not multiple, less pressure on file system
  • No decoding file format, it’s only unserialize
  • No decoding value from string to int
  • No endian change
  • Only used information is kept, no useless data is loaded

6H to 5min for CatchChallenger compilation time

How I had pass from 8H to compile my catchchallenger cluster nodes to 5min?

  • Firstly be sure the only minimal header is included into your sources files
  • I use same OS on all my nodes on same architecture, compile on one node by devices, not on all nodes (lower the concurrency) and copy the binary. Very lower memory pressure, not use swap

With this I have passed from -j1 compilation to -j9, then it’s very more powerfull too. And finally my time to compile is very low.

http3 in Confiared

Hi,

I have already finish the support of http3 for Confiared, but not pushed in prod because I need check more it.

The next week I will work on it, for Americ South (as Bolivia), one of interesting part is the http3 is more RTT insensitive. Mean: for https, it wait very less time before start to download the web page.

It will be firstly enable on IPv4 reverse proxy for our VPS and hosting, to get it on your servers.

Cheers,

Mimic UDP with TCP

Hi,

My problem was: I have a game (CatchChallenger), I need update the player position on other player, but if newer data is here, not send the old data. Not send all vector change (pos + direction). But my game is in TCP.

Put the socket buffer to small size, if you do it into:

  • Async: when EEGAIN receive, store the last pos into buffer with method: last data override the content, when you don’t have EEGAIN you can start send the buffer
  • Sync: You need use thread, it’s same method as above, but you don’t use EEGAIN, just: bool eegain=true;write(data);eegain=false;

As this you have: packet in writing (then can’t change), X dropped data due to wait of writing buffer free, and the last pos send. Exactly as UDP, but with the TCP advantage as packet order (and the small tcp packet overhead)

If you like this tips, follow me on facebook and linkedin.

Cheers,

Fuzzing continue

Bonjour,

Je suis en train d’implémenté du fuzzing continue, wikipedia a une bonne définition:

Le fuzzing (ou test à données aléatoires) est une technique pour tester des logiciels. L’idée est d’injecter des données aléatoires dans les entrées d’un programme. Si le programme échoue (par exemple en plantant ou en générant une erreur), alors il y a des défauts à corriger.

J’ai une infrastructure de teste, je lance de forme continue via les bots que j’ai mentionné dans l’article précédent. Cela permet de détecté des bugs avant que les joueurs ne s’en rendent compte.

J’ai couplé cela à des techniques de pointe comme le sanitizer software utilisé par google dans chrome (cf: OSS-Fuzz), qui permet de détecter les buffer overflow et autre bug/crash/faille de sécurité. Ce qui m’as permit de détecté encore plus de bugs et une fois corrigé, cela me permettra de fournir une meilleur stabilité.

Bye

 

 

 

Botnet vs cluster

Bonjour,

Je viens de finir les bots pour CatchChallenger, du moins juste un truc basique comme base de travail. Cela peu servir de botnet d’attaque DDOS contre CatchChallenger. L’attaque est spécialisé donc vraiment très efficaces, mais la défense (dons les filtres anti DDOS intégré) ne permette pas d’attaque sauvage.

sachant que rien n’est optimisé. Face aux bots, le serveur consome 20x moins de CPU, 5x moins de mémoire.

Bye

Map chunk et déplacement

Les maps modernes se charge par parties, cela permet d’éviter de charger des ressources en mémoire inutilement et donc de fluidifier le jeu pour en améliorer l’expérience. Chaque morceau de map (ou Map chunk en anglais) est en générale une section de taille fixe dans le cas de génération procédurale typiquement.

Cela ajoute des difficultés de gestion dans le code. Les détections de collision doivent être multi-map. Les éléments pouvant circuler d’une map a l’autre doivent être déchargé d’une map puis chargé dans l’autre.

En UDP des données de déplacement sont non continue, en TCP elle peuvent être continue ou non. Pour le client side prediction, donc que l’autre joueur continue sur sa lancée ou son mouvement en cour, il faut donc transformer cette chaine de point/direction typiquement en un movement, pour ne pas alourdir les calcules dans CatchChallenger je n’utilise pas de pathfinding a ce niveau (et donc je m’évite DDOS coté client et surcharge).

Voila comment un jeux moderne fonctionne, 2D ou 3D. Bye

P2P pour CatchChallenger

Salut,

Le P2P est pour le backbone de CatchChallenger. Pourquoi?

Le but premier été de supprimer le Single Point Of Failure, ou le seul point unique qui pouvez tomber tout le réseau.

Bien que pratique, le TCP (surtout avec le chiffrement), posais beaucoup de problème avec le P2P, surtout ce point: ont ne pouvais pas se connecter sur le port émetteur, donc il fallarais se connecter sur un autre port (transmit d’en face, sans garantie qu’il soit fonctionnel).

J’avais besoin d’un réseau sécurisé (authentifier de forme générale, chiffré à certain endroit). L’UDP est sensible as un certain nombres d’attaques (comme les attaque replay). Le protocole UDP est souvent utilisé comme amplificateur. J’ai donc du redévelopper une couche dédié pour répondre à ces besoins.

J’ai besoin d’être résistant a une node compromis, donc pouvoir blacklister sa clef publique. J’utilise un dérivé des autorités de certification pour faire que la clef publique est reconnu par le réseau et une clef maitre broadcast des clef a ban sur le réseau (et autre ordre).

Cela m’as fait travailler sur beaucoup de domaine parallèle (Database NoSQL + lockless), maintenant je suis dans la phase d’implémentation.

Bye

Khronos ouvre ces testes de conformité OpenGL

Bonjour,

Je voulais faire cette article il y as longtemps. Lorsque l’on fait un standard, un certain nombre de points sont important pour une acceptation naturel (non forcé par un monopole).

  • Que le standard soit ouvert: que tout le monde puisse utiliser ce standard sans payer de brevet (garantie d’interoperabilité)
  • Quel la documentation soit ouverte: Pour éviter les sur-cout lié au reverse engineering
  • Favorable: Que le code ou la lib soit ouverte pour pouvoir l’étudier, vérifier et corriger
  • Les testes de conformité pour savoir si cela respecte bien la norme

Il existais déjà les testes de conformité pour vulkan, maintenant les testes de conformité pour OpenGL sont sortie.

Je remerci Khronos pour ce geste. Cela vas permettre une propagation rapide du standard, car tout les drivers open sources vont pouvoir vérifier leur conformité.

Note: Même si maintenant la plus part des drivers sont OpenGL 3+ sous Linux, il y as encore des problèmes de performance, des problèmes divers sur le hardware qui viens juste de sortir. Et un manque de support natif, open source et intégré de OpenCL, Vulkan.