C10B

After C10k (10 000 concurrency connections), C10M (10 000 000 concurrency connections), now C10B is near (10 Billions concurrent connections, 10Tbps, 10 billions packets per seconds, 1 billion connections/seconds). In my case: 1 Billion concurrent connections, 1Tbps, 1 billions packets per seconds, 1 millions connections/seconds)

I have test it with CatchChallenger, with 32 core Threadripper 2990WX , 256GB DDR4, Radeon RX Vega 64.

This experiment can be used for high speed network packet processing for ethernet 100G+ or infinityband device. I have do as R&D for my company router with 1Tbps (at 64B packet size) routing capability certified with benchmark.

I have do stateless filter on IPv6 input, each processing unit after do the state-full work, but with an special dispatching memory access to reduce the cache miss. Mean: IP/TCP processing GPU, CatchChallenger processing CPU.

Difficulty: Very limited into memory, I had used specialized swap technique with barer to delay some class of trafic (move on map: 95% of move, + not published protocol with another vector move to prevent memory access and only parse last pos with need to use previous data), bulk processing of this.

Result:
59ms average reply time
95% 342ms reply time
Burn 1.2Tbps of network bandwidth

Ref: https://link.springer.com/chapter/10.1007/978-3-642-24999-0_44

Ref2: https://shader.kaist.edu/packetshader/

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