CatchChallenger – Domaine first-world.info

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

Génération procédurale de la map

Bonjour,

Vous vous demandez peu être ou j’en suis avec la génération procédurale de la map pour CatchChallenger.

Bien qu’il reste des mois de travails, pour avoir juste une map de base, cela avance.

Les villes sont là, certaine avec des bâtiments complexe. C’est basé sur des template statique sont seront fait dynamiquement plus tard.

Les routes ne sont que des lignes droites. Je travail sur la répartition des espéces.

Cela m’as permit de voir certain bug et noté une serie d’amélioration a faire.

Je continue à explorer d’autre piste comme le deep learning et machine learning pour la génération automatique.

J’améliore mes compétances en d’autre domaine (bioinformatique, physique quantique, fibre optique, …), pour mon enrichissement personnel.

Je prépare aussi la conférence que je doit donner sur les télécommunications en bolivie. (hackmeeting 2017)

CatchChallenger ces derniers temps

Bonjour,

Status des serveurs et nombre de joueurs

Map avec les info de debug, fait via les diagramme de voronoi

Je pas mal travailler sur un certain nombre de points sur CatchChallenger, qui en passant a plus de 5ans.

Pour commencer les bots, il joue automatiquement et permettent donc pour moi d’avoir une charge proche de ceux des joueurs. Ce qui me permet de tester et benchmarker mieux les serveurs.

J’ai amélioré le monitoring, il est plus sensible et permet de tester des chaines complète de connexion et de style de jeu via les bot mais aussi divers mécanismes de jeux pour s’assurer qu’il n’y as pas de bug dans les serveurs. J’ai en passant recu divers chose pour mes odroid, dons plusieurs afficheur LCD, dons un que vous pouvez voir en photo.

Je remercie confiared qui est une entreprise d’innovation en technologies en bolivie, dons le secteur d’activité principale tourne autour des serveurs et datacenter. Qui as fourni des meilleurs serveurs de teste mais aussi la connectivité IPv6 avec des IPv6 publique pour connecté ces serveurs. Actuellement elle fourni des VPS, avec des cms préinstaller, il est prévu que CatchChallenger en serveur simple soit proposé à coté des autres cms. L’entreprise vas aussi ouvrir ces offres de hosting. Donc potentiellement il y aura des serveurs CatchChallenger clef en main. Les eMMC (SSD orienté Odroid) ont été installé dans leur machines.

Comme vous pouvez le voir plus haut, je travaille aussi sur la génération de map. Dans le but de compenser les manques de contenu et de ces mises a jour. Facilité le travail des mapper en ayant des map préfabriqué. Mais cela permet aussi de varier les expériences de jeu. Cela peu être associer a un système de note pour ne garder que les meilleurs contenu.

Les concours de CatchChallenger seront ouvert a la suite de cela, pour donner une base une base de programmation pour les segment visé, avec des prix a gagner.

Bye, je retourne coder.

DDOS a 1Tbps!

Salut,

Je viens d’avancé sur les bots, ce qui m’as permit de lancé une attaque DDOS de 1Tbps sur mon cluster locale de odroid c2 (boucle locale: localhost), 5.2Gbps par odroid c2 par coeur. Ou 100 000 joueurs sur un rpi1 ou pentium 1/2 a 200Mhz. (Cela est approximatif et vas dépendre de comment jouent les joueurs)

Les serveurs fonctionnais sans ralentissement visible coté client (et avec les pires réglages). Ce qui est un nouveau records mondiale et confirme les chiffres suivant: 10 Millions de joueurs possible par serveur pour un serveur moyen.

CatchChallenger n’est pas encore optimisé a fonds, mais cela n’as pas d’importance. Il faut environs 10 000x plus de puissance offensive que défensive.

Quand on affronte 2 bots ou botnet vs Waf avec des IA, une qui cherche à défendre (essayant de trier vrai visiteur et bot) et l’autre à attaquer (essaye de simuler la charge visiteur mais avec les actions ralentissant le plus possible le temps de réponse générale du serveur, avec webkit), les 2 bots se mettent au niveau jusqu’as un point d’équilibre qui ne permet pas de distinguer un bot d’un visiteur et n’est pas différentiable d’un gros coup médiatique.

Bye

Prepared statement in C

Hello,

I have not found any real code to prepared statement in C for PostgreSQL.

Then I have do it:
prepared_statement.c on CatchChallenger code

Prepare, mean: fix, optimise and cache the execution plan, this prevent any change to execution plan and improve the security too

Cheers,

PS: inspired by http://zetcode.com/db/postgresqlc/

Le format TAR

Pourquoi je l’utilise? Car c’est un format libre, ce qui garantit l’interopérabilité. Cela est important car cela me permet d’avoir toujours un logiciel pour faire et lire l’archive, sans license ou redevance. Cela permet d’encoder un tar sous Windows, Linux, Mac. Le faire ma propre lib pour le lire (donc réduire la taille du code car je limite les fonctionnalités à ce que j’ai besoin).

Cela me permet de découplé le format de stockage et la compression en elle même. Utiliser le format Tar avec gzip, zlib ou autre.

Comment est fait un Tar?

Vous avez les données, le contenu des fichiers. Et les métadonnées, nom, chemin, chmod, utilisateur, groupe, date de creation… Le format Tar tar fonctionne par bloque, les trous entre les bloques sont remplit par des 0 binaires. Le format est orienté stockage sur bande, il date de 1979 (normalisation 1988) mais eu des revisions entre temps.

Le fait de ne pas faire une bête sérialisation peu être gênant pour les systèmes de compression car il y as un trou de X 0 binaire. Cela rajoute du bruit, ce qui est problématique pour optimiser la compression. Si en plus l’on rajoute le faite que les entier sont stocké en chaine, ce qui réduit encore le ratio de compression comparé au binaire (voir: Compression et Binary dans le wiki de CatchChallenger). Cela réduit aussi les performances de l’encodeur et décodeur Tar de travailler en chaine et non pas en binaire (sans parler des limitations de la longueur des nombres représentés).

Un format mieux étudié pourrai avoir une taille bien inférieur sans compression et un meilleur ratio de compression.

Supprimer des meta données serai une bonne idée. Par exemple dans mon décompresseur je ne prends en compte QUE le fichier et son nom et j’ignore une grande partie et méta données: chmod, utilisateur, groupe, date de creation…

Conclusion

Je vais continuer à utiliser Tar dans le cadre de mes logiciels pour faciliter la création de plugin pour Ultracopier/Supercopier et pour l’intégration facile coté serveur dédié (99% de unix) pour CatchChallenger via un mirroir http (car pour le self hosting il y as déjà un rsync simplifié qui rends toute utilisation de Tar inutile).

Faire mon propre format n’est pas un probléme, le probléme serai de faire/maintenir et distribuer l’encodeur et le décodeur pour ce format.

MongoDB vs CassandraDB vs Autre pour CatchChallenger

Bonjour,

Pour les besoins de CatchChallenger, j’ai exploré des base de données NoSQL.

CassandraDB

C’été mon 1er choix. La mise à l’échelle (scalabilité) est bonne. Il prends en compte le datacenter.

Mais le pannel de controle fort sympatique qu’est OpsCenter est réservé a RedHat et debian, pourquoi il ne peu pas juste demander les dépendances qu’il as besoin, voir les embarqués si elle ne sont pas trés commune?

J’ai été obligé de rajouter des clef primaire la ou ce n’est pas utile. Les index uniques sur du multi colonne ne sont pas natif et vu que j’ai rien compris sur comment faire ce CUSTOM INDEX et que cela affecte les performances, j’ai dit adieux.

MongoDB

Sur gentoo, je suis bloqué en 2.6 à cause d’un conflit de dépendances avec kleopatra (KDE). Même si c’est plus de la faute de kleopatra, c’est génant.

J’ai donc tenter sur un de mes ARM, et là on me dit que sur ARM, et particulièrement ARM 32Bits cela ne sera jamais supporté. Donc poubelle.

MariaDB

Bien, compatible car j’utilise des functions simples (ce qui me rends compatible avec 100% des SQL), je note cependant que certaines fonctionnalités ne sont pas dispo sur toute les architectures: TokuDB pas dispo sur ARM…

Petit coup de guele

Nous somme en 2016 les gas! Mềme Mingw supporte gcc 4.9, ce qui donne accès a une abstraction à la fois de l’architecture et de la plateforme.

Pour être indépendant de la plateforme il y as plein de libs connu, sans compter la compatibilité entre les unix, et grace à mingw avec windows.

Coté architecture, il faut toujours avoir un failback en C/C++ pour les architectures moins optimisé mais pour avoir un support et du code lisible et vérifiable. Le double support 32Bits et 64Bits est super facile à faire si ont respecte la norme. Hors mit ca je vois pas la moindre raison que votre code C/C++ ne marcherai pas sur une autre architecture.

Le 32Bits ne vas jamais disparaître car c’est le moyen le plus effectif pour avoir des système embarqué avec peu de consommation. En plus cela permet de réduire lors d’utilisation forte de pointeur l’empreinte mémoire (jusqu’as 2x de réduction, BTree, hash table, …). Si vous utilisez moins de 4Go de mémoire, le 32Bits est fait pour vous. C’est pour cela qu’existe aussi x32, cela permet sur x86_64 de tiré partie du mode 64Bits mais en ayant un mode d’adressage en 32Bits (donc max 4Go) mais avec la réduction de l’empreinte mémoire du 32Bits. Cela ne me surprendrai pas de savoir que les GPU ont des cpu en 32Bits.

Bye.