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.

Répartition des espéces
Répartition des espéces
Overworld avec 3 villes
Overworld avec 3 villes

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

 

Minimap
Minimap

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
Map avec les info de debug, fait via les diagramme de voronoi
Map sans les debug et avec les plantes
Map sans les debug et avec les plantes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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).

Tar and gzip
Tar and gzip

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.

Les dépendances

Bonjour,

Je suis tomber sur cet article:

http://thebacklog.net/2011/04/04/a-nice-picture-of-dependency-hell/

Voila la visualisation des dépendances des logiciels et libs:

gentoo graphic dependency hell

Il y as des dépendances dans tout les sens, mais le pire c’est les dépendances circulaires, il vous faut A pour avoir B, mais B pour avoir A… et donc comment vous faite depuis 0? Vous mettez un A compilé trouvé sur internet, vous compilez B, puis compilez A et écrasez le A de internet.

En 5 ans le nombres de packets à augmenté, les dépendances se sont complexifié. Cela rends la maintenance d’un OS plus compliqué. Faire l’arbre de dépendances pour calculer les dépendances à installer avant le packet deviens de plus en plus complexe.

Un logiciel peu vouloir une lib en version 1.2 et pas moins ni plus, et un autre utilise cette libs en version 1.3 minimum.

Vous développeur, que pouvez vous faire?

A votre niveau, que pouvez vous faire? Voila une serie de conseille qui sont à appliquer avec intelligence, et non comme des régles strictes:

  • Minimiser le nombre de dépendances: Cela permet de rendre la compilation plus facile pour les contributeurs potentiels. D’avoir moins besoin d’adapter votre logiciel pour les changements d’API des libs que vous utilisez. Augmente les performances de votre logiciel (1 relocation en moins, peu être critique quand vous l’appelez comme un fou dans une boucle) et permet à votre compilateur le LTO et/ou d’inline la fonction qui vas bien et d’utiliser moins de mémoire. Permet de minimiser la taille en supprimant tout les codes compilé peu/pas utilisé. Cela permet de minimiser les failles en minimisant le code chargé et donc le nombre de faille potentiel. Comment? En analysant les choses que vous n’utilisez pas: Certain lie des libs sans même utiliser la moindre functions. Si vous utilisez très peu de function d’une libs, il est souvent plus intéressants de refaire ces functions dans votre programme (sauf si vous ne voulais pas avoir à charge leur maintenance: par exemple les functions de hash de openssl qui sont actualisé pour exploiter au mieux les instructions du cpu)
  • Etre tolérant sur les versions de libs supporté: Cela permet de ne pas rentré en conflit avec d’autre logiciel demandant une version supérieur ou inférieur d’une lib. Comment? En ne pas se jetant sur la dernière fonctionnalité de vos libs (mais utiliser la si c’est un avantage majeur: J’utilise dans Ultracopier Qt 4.4 pour la détection de l’espace libre, impossible de faire autrement sans rajouter une dépendance problématique)
  • Pour le packaging sous Windows, vous pouvez utiliser une copie privée de vos dll, et donc avoir des versions spécifique sans que cela rentre en conflit avec les autres logiciels. Cela n’est pas applicable au OS qui mettent en commun les lib et qui ont une gestion de packets.

Si vous faite une lib

Si vous faite une lib, voila les conseilles:

  • Dépendance: évitez de mettre en dépendance une libs qui directement ou non dépende de votre libs.
  • Versioning et API: Exploser une API stable, que vous aller changer un minimum de fois en cumulant les changements. Mettez un numéro de version, avec un nombre majeur caractérisant un changement d’API, et un nombre mineur pour les changements interne qui ne change pas l’API.

Voila, en espérant vous avoir éclairé.

Load balancing et scalabilité avec CatchChallenger

Bonjour,

Je rentre dans une phase de testing, benchmarking et stabilisation dans CatchChallenger. Je n’est pas encore fait l’optimisation, juste respecter les régles de codage.

Les temps noyau, et gestion de matériel dans le cas du raspberry pi sont bien supérieur aux temps en espace utilisateur. Donc un load balancer prendrais autant de charge CPU que l’application en elle même. Le seul cas réel d’un load balancer serai un gros load balancer et de toute petite nodes. Mais dans tout les cas le load balancer ne pourra jamais gérer plus de client que les nodes elle même.

Pourquoi un load balancer?

Pour la haute disponibilité: Il suffit de faire soit un/des haproxy en mode tcp, ou faire cela via DNS (ce qui permet de faire des personnalisation par pays pour optimiser le trafic, et cela est parfaitement scalable)

Répartition de charge: impossible via un logiciel si les serveurs sont symétrique, car il passerai plus de temps cpu a répartir la charge que à travailler (induirai des latences et sous chargerai les serveurs). Pour les serveurs logins, la gestion par pays des DNS permet cela.

 

Et pour les games serveurs? Pour la haute disponibilité: Pas besoin, le serveur est down, les joueurs peuvent aller jouer sur un autre serveur similaire. Répartition de charge: Les limites par serveur force les joueurs a se répartir sur les différents serveurs, sans compter avec le faire qu’il vont sur les serveurs les plus proches de chez eux.

 

Un raspberry pi 1, ARMv6 à 700Mhz tiens une charge de 60000 joueurs. Ceux sans optimisation. Pour que une attaque DDOS soit intéressante il faut que le prix de l’attaque soit bien inférieur au prix du préjudice. Comme ici le botnet pour attaquer CatchChallenger doit être vraiment três grands face aux peu de serveur pour surporter un tel charge, la possibilité d’une attaque DDOS est relativement faible.

Attention: Les options du serveurs ont une forte influence sur la monté en charge et le confort des utilisateurs.

Map infini

Les maps infini sont théoriquement supporté (infini à la minecraft: trop grande humainement pour être explorer). La gestion et mise a l’échelle as été fortement amélioré. Il deviens donc envisageable de faire les maps par génération procédurale.

Raspberry pi 3

Je ne vous conseille pas le raspberry pi 3 car pour le même prix vous avez the le Odroid C2 qui vous offres: une bien meilleure carte graphique, une mémoire bien plus rapide, plus grande, un meilleur bus de communication entre les composants, une carte réseau meilleure et mieux interfacé (pas via l’usb), l’eMMC, …

 

N’hésité pas a acheter les logiciels qui vous ont plus ou apporté quelque chose (CatchChallenger).

Bye,

Comment augementer votre compression sans toucher au format de compression?

Bonjour,

Aujourd’hui nous allons parler de compression de données lossless (sans changement de l’information).
Cela vas s’appliquer surtout au MMORPG CatchChallenger sur les points suivant: données de taille petite et moyenne, fortement compressible (xml, base64 continue).

Choix de la compression

Même si dans ce post se n’est pas le but, il faut bien choisir votre compression en fonction de votre système. Si vous voulez plus de bande passante en échange de cpu, si vous faites la compression dynamiquement ou non, …

Ratio de compression

Temps de compression

Réduire l’entropie

Nous allons avant tout commencer à reduire l’entropie. Vous devez donc supprimer toutes les données aléatoire inutile. Et faire que celle utile forme des suites.

Isoler les bloques aléatoires

Quand un bloque de donnés viens couper des données similaire:

items/1073.png 1 XXXX
items/1149.png 1 XXXX
items/1178.png 1 XXXX

Cela casse la compression (le système de compression switch tout le de temps compressé a non compressé). Cela n’as pas d’importance sur les grands bloque car le changement de mode est mineur vis a vis de la taille du bloque à compresser. L’idée est donc de les mettre la la fin pour que la compression soit maximal d’un coté et que le système de compression marque simplement un gros bloque comme non compressible.

items/1073.png 1
items/1149.png 1
items/1178.png 1
XXXX
XXXX
XXXX

Cela fait gagné 20% sur le format au dessus.

Binaire et pas hexa

Les formats de compression sont très sensible aux données non compressibles, les mettre en binaire et pas en hexa permet de réduire leur taille (10%).

Contenu

En fonction du contenu ET de la taille certaine compression seront plus avantageuse. Par exemple la zlib/gzip est plus efficace que xz/lzma sur les packet <300o.

Il n’y as pas une compression meilleur que les autres, chaque une ont leurs caractéristiques et leurs caractéristiques vis à vis de certaines données.

Zopfli

Zopfli permet de garder le format de compression actuel, mais à énormément besoin de cpu, ne jamais l’utiliser en dynamique. Il réduit de 10% à 50% la taille de vos compressions zlib/gzip (donc png aussi)

Mon outils tmxTileLayerCompressor pour compresser les bloques zlib dans les tmx avec zopfli permet de réduire la taille des tmx même sous leur forme compressé d’environ 10%.

Chose étonnante je ne constate pas de réduction de taille du datapack.tar.xz comme prévu. Idem coté tar sans xz, je pense que la modification est noyé dans un volume tellement gros d’informations qu’elle n’as pas d’influence. Par contre sur les pngs zopfli a une une influence notable.

Brotli

Je doit tester cette compression qui semble sympa surtout pour le streaming réseau avec des bloques de plus de 800o. Une compression proche de xz pour le statique, mais plus performant que gzip en -6 pour le streaming réseau tout en conservant un trés bon ratio. Mais hélas je trouve qu’il est trop orienté décompression, car la compression est bien trop lente mon gout, où en -6 c’est trés proche ou inférieur au ratio de zlib en fonction du contenu. Comme zlib: C’est parallélisable? Possible accélération hardware?

Voir le super lien: https://quixdb.github.io/squash-benchmark/

Lossy

Pour certain fichier comme les png/audio, les compressions sont lossless (sans perte de qualité/informations) mais j’ai appliquer un filtre de compression lossy (perte de qualité/informations) pour réduire la taille.

CatchChallenger

Voila les résultats spécifiques à CatchChallenger pour la liste des fichiers à télécharger:

Binaire 7% de taille en moins pour gzip
Suppression des retours de ligne pour les hash partiel (données non compressibles: réduction de 10% pour xz, 7% pour gzip
La spéparation en deux fichier (l’un compressé l’autre non) fait gagné 100o mais qui sont perdu par le protocole http (2x les entêtes pour les deux fichiers)
Répartition de la taille pour la base:
* 7Ko pour la liste de fichiers
* 500o pour la taille des fichiers
* 12Ko pour les hash partiel (non compressible)
Répartition de la taille pour le main:
* 2200o pour la liste de fichiers
* 500opour la taille des fichiers
* 2200opour les hash partiel (non compressible)

Programmation Broadcast vs singlecast et chat

Bonjour,

J’avais vu une bétise sur internet disant qu’il valais mieux utiliser une serveur irc pour le chat de votre jeu pour les performances. Si vous êtes sur le même hardware et que irc fait beaucoup mieux alors c’est que vous avez mal codé votre programme.
Buffer
Le principe basique est d’envoyer le message à tout les clients connectés.  Si le buffer n’est pas assez grand, ou le message/liste de client trop grand, alors votre programme vas être bloqué à chaque écriture dans votre socket et donc ne vas pas pouvoir tourner. Vous pouvez pour contourner cela en l’isolant dans un thread (cela vaut pour tout les autres syscall bloquant) ou passer votre socket en mode non bloquant (plus de travail mais plus de performance).
Packaging
Vous avez plusieurs couche, hélas la plus par du temps vous ne pouvez pas directement accéder au buffer tcp, mais ce que je vais vous dire vaux pour les couches suppérieures. J’ajoute en header un code de packet et une taille, donc pour du broadcast je compose le packet complet (avec header), et je l’envoie, ce qui est bien plus efficace que de le recomposer à chaque fois inutilement (cela demande des fast path dans le code, et une décomposition total pour le controle de la sortie). Le CRC32 du tcp est aussi calculable qu’une seule fois, mais l’OS ne propose en générale pas d’interface pour cela.
Application tiers

Le faite de rajouter un application n’as de sens que si le client se connecte directement a elle et qu’elle est sur un autre serveur, mais personnelement je ne vois pas comment ont peu saturer un serveur irc ou un chat avec un usage normale. Le faite de communiquer entre le serveur et un autre serveur rajoute une couche tcp et de message qui fait plus de consomation cpu/réseau/mémoire.

Ces principes valent aussi pour les déplacements des joueurs qui sont aussi envoyé d’un block à tout les joueurs dans la même zone.
PS: avec un « \0 » bien placé ont peu cacher des données dans le chat de maniére discréte