Discussion :

[alpha_one_x86]

Donc, en fait, tu envoies tous les mouvements de tous les joueurs à tous les autres joueurs ? Tous tes joueurs peuvent vraiment se voir ?

Ca dépends ce que tu entends par la. J'ai plusieurs algorithme pour ça. l'un des plus simple, c'est qu'il peuvent ce voir mutuellement si il sont sur le même segments de map (bonne performance). Un autre en fonction de la distance. Le tout avec des hysteresis. Bref, ici je simplifie trés trés fortement les choses.

Donc tu es au courant que tes benchmarks sont optimistes. Donc tout va bien. Même si, en général, on considère qu'il vaut mieux être pessimiste, mais bon...

Je par du point de vue pessimiste -> changement de direction aléatoire par exemple, alors qu'un vrai joueur vas plutôt en ligne droite (donc plus de performance).

Là, j'ai du mal à comprendre... Tu fais tant de calculs ?

C'est la complexité carré qui fait tout bloquer. Point de vue pessimiste: Je par du principe d'avoir 400 joueurs sur le même segment de map. Donc 400*400=160000, si je prends juste 10 personne par segments de map ça fait avec l'algo visible par map: 1600 joueurs supportés.
Aprés je mieux c'est un profiler sur un serveur en exploitation.

chiffrement*
Sinon... Pourquoi chiffrer la connexion ? Et puis, vu que le cpu semble le facteur limitant (et de loin), es-tu sûr qu'il est une bonne idée de compresser ?

C'est des options activable ou pas. Après exemple, si ont héberge chez soi, avec 10 joueurs, vaut mieux activé la compression, car le facteur limitant vas largement étre l'upload sur le serveur. Et certaine trames sont presque que des 0x00, donc autant avoir une compression. Surtout que la lzo, lz4, ... compresse à quelque giga par secondes sur ma config.

16000 paquets par seconde maximum ?

Par secondes.

Tout le protocole est encodé en UTF-16 ? Ne faudrait-il pas plutôt appliquer ça aux messages entre joueurs seulement?

Mal exprimé, corrigé. Protocole binaire, mais chaines en UTF-16.

16 bits pour le sous-code ? Tu as un main code qui a plus de 256 sous-codes ?

Comme dit avant, c'est une ébauche. Pour l'instant je ne sais pas vraiment ce que j'ai besoin ou pas, donc je prévois large.

Utiliser un octet pour stocker la valeur d'un bit (seulement deux valeurs possibles), c'est du gâchis, hein.

Pas compris, ici c'est un entier que je stock.

Que se passe-t-il si la vérification serveur ne colle pas avec les calculs du client ? (i.e. overclocking trop poussé et erreur dans les calculs du client)

Ont considére que le client tante de tricher, il est immédiatement kicker. Par contre je ne suis pas sur si je fait juste ça ou autre chose.

L'anglais nécessiterait bien une vérification.

+1, et les correcteur orographique sont merdique.

Il est donc forcément plus long.

Justement j'avais compris le contraire, plus aléatoire, mais plus rapide que tout les méthodes traditionnelles, j'avais entendu parler de 40Mo/s de données aléatoires.

Hum... Pour autant que je sache, Qt 2D est assez peu apprécié.
SFML pourrait probablement être un meilleur choix.

Peu étre, bref, il me faut une lib 3D, et c'est le dev en charge de cette partie qui choisira. Faut juste une lib qui supporte les animations, effet graphique (luminosité, saturation, les masques par calques, ...)
Aprés il y as Qt 2D (QGraphicView -> brof) et Qt 2D (QML2 -> qui semble être bien).

[Ekleog]

Je par du point de vue pessimiste -> changement de direction aléatoire par exemple, alors qu'un vrai joueur vas plutôt en ligne droite (donc plus de performance).

Surtout que si tu lances tous tes bots à partir de la même position, ils vont en moyenne rester tous collés au même endroit... :/
Là, c'est peut-être un peu trop pessimiste, je crois.

C'est la complexité carré qui fait tout bloquer. Point de vue pessimiste: Je par du principe d'avoir 400 joueurs sur le même segment de map. Donc 400*400=160000, si je prends juste 10 personne par segments de map ça fait avec l'algo visible par map: 1600 joueurs supportés.
Aprés je mieux c'est un profiler sur un serveur en exploitation.

1600 segments de map*, non ?
Si tu penses qu'il est impossible d'avoir 400 joueurs sur une même map (au besoin, il est toujours possible de poser une limitation), alors tester avec 400 joueurs sur une map est inutile. Surtout que ça fausse le bench en s'aidant du cache, alors qu'avec plusieurs maps il y aurait probablement plus de diversité dans les emplacements mémoire accédés. Il serait plus efficace de tester directement avec 20 personnes par segment de map. (20 pour rester pessimiste)

C'est des options activable ou pas. Après exemple, si ont héberge chez soi, avec 10 joueurs, vaut mieux activé la compression, car le facteur limitant vas largement étre l'upload sur le serveur. Et certaine trames sont presque que des 0x00, donc autant avoir une compression. Surtout que la lzo, lz4, ... compresse à quelque giga par secondes sur ma config.

Y a-t-il vraiment besoin de chiffrer un protocole de jeu ?
"le facteur limitant vas largement étre l'upload sur le serveur"
-> Je croyais que le serveur tournait à 100% avec une BP de 10Kbps ? Pourtant, 10Kbps, qui n'a pas ça en upload, même sur de l'ADSL, voire même sur le câble ?
"Surtout que la lzo, lz4, ... compresse à quelque giga par secondes sur ma config."
-> Considérons 1Gbps de compressé. Pour compresser un paquet de 10Ko (taille encore raisonnable, vu que tu transmets tes listes par lots), tu consommes 1.9 µs de cpu. Et puis, ton programme tourne, en même temps. Et on peut supposer que l'utilisateur aura d'autres programmes allumés, et que la compression ne se verra allouer que ~10%cpu. Donc la compression consomme 19µs cpu par paquet, en moyenne. Ce qui est énorme !

Par secondes.

16000 paquets/sec.
Même avec 1Kio/paquet, ça fait 16Mio/sec de vitesse matérielle. Ca ne me semble pas totalement ridicule, pour un framework qui n'est pas fait pour ça à la base.

Pas compris, ici c'est un entier que je stock.

Un entier qui, au moins pour le moment, ne peut prendre pour valeurs que 0x01 et 0x02. Donc... C'est l'équivalent d'un bit de données.

Ont considére que le client tante de tricher, il est immédiatement kicker. Par contre je ne suis pas sur si je fait juste ça ou autre chose.

Pourquoi ne pas simplement annuler l'action et envoyer un message au client ?

Justement j'avais compris le contraire, plus aléatoire, mais plus rapide que tout les méthodes traditionnelles, j'avais entendu parler de 40Mo/s de données aléatoires.

Selon http://www.boost.org/doc/libs/1_49_0...rformance.html ; mt19937 gagne la course parmi les générateurs software, avec 204 Mwords / second, soit 816MBps. Sous windows, c'est encore plus efficace.

Peu étre, bref, il me faut une lib 3D, et c'est le dev en charge de cette partie qui choisira. Faut juste une lib qui supporte les animations, effet graphique (luminosité, saturation, les masques par calques, ...)
Aprés il y as Qt 2D (QGraphicView -> brof) et Qt 2D (QML2 -> qui semble être bien).

Lib 3D ou 2D ?


Pour en revenir au sujet de base, as-tu finalement résolu ton problème initial ? Si oui, comment ?

[alpha_one_x86]

Si tu penses qu'il est impossible d'avoir 400 joueurs sur une même map (au besoin, il est toujours possible de poser une limitation), alors tester avec 400 joueurs sur une map est inutile. Surtout que ça fausse le bench en s'aidant du cache, alors qu'avec plusieurs maps il y aurait probablement plus de diversité dans les emplacements mémoire accédés. Il serait plus efficace de tester directement avec 20 personnes par segment de map. (20 pour rester pessimiste)

D’après mon expérience et ce qu'ont m'as retourné. Il est fréquent d'avoir sur de courte période, un attroupement, lors des event organisé par les admins, pour gagner un objet unique. Ca regroupe fréquemment 50% du serveur. Aprés il y a des parades, j'ai mit un limite avec un hysteresis, pour ne plus afficher les joueurs de la map courante aprés une limite, et il y as d'autre algo. Mais ça reste des parades.

Y a-t-il vraiment besoin de chiffrer un protocole de jeu ?

Pour les hardcore gamer oui, car il y passe 16h par jour, et veulent pas ce faire pirater leur compte. Idem pour ceux qui utilise le même mot de pass partout. Théoriquement toutes les transmissions devrai être crypter, sans faire distinction de ce qui est important ou pas (ce qu'apporte l'ipv6 avec ipsec).
Après, ça reste facultatif.

-> Je croyais que le serveur tournait à 100% avec une BP de 10Kbps ? Pourtant, 10Kbps, qui n'a pas ça en upload, même sur de l'ADSL, voire même sur le câble ?

C'est dans un cas très exterme, dans un cas + réaliste ça peu monter. Les personnes ont souvent 40~50Ko d'upload en pratique avec l'adsl. Et plus ont ce rapproche de cette limite, plus les données attendes leurs tour car d'autre données sont envoyé, et plus les latences explose (encore un argument pour minimiser/supprimer l'influence des latences).

"Surtout que la lzo, lz4, ... compresse à quelque giga par secondes sur ma config."
-> Considérons 1Gbps de compressé. Pour compresser un paquet de 10Ko (taille encore raisonnable, vu que tu transmets tes listes par lots), tu consommes 1.9 µs de cpu. Et puis, ton programme tourne, en même temps. Et on peut supposer que l'utilisateur aura d'autres programmes allumés, et que la compression ne se verra allouer que ~10%cpu. Donc la compression consomme 19µs cpu par paquet, en moyenne. Ce qui est énorme !

Ce qui reste bien inférieure au temps de transmission, au temps d'une requête... et maintenant si je transmet 1Mo ou 1Ko, c'est pas le même temps à 50Ko/s...

Même avec 1Kio/paquet, ça fait 16Mio/sec de vitesse matérielle. Ca ne me semble pas totalement ridicule, pour un framework qui n'est pas fait pour ça à la base.

D'un autre coté, Qt ceux veux pas que une lib de GUI, donc qu'il fasse les choses correctement. Ce qui est suffisant (et si j'ai besoin de +, je peu le faire moi même ou utilisé une autres libs)

Un entier qui, au moins pour le moment, ne peut prendre pour valeurs que 0x01 et 0x02. Donc... C'est l'équivalent d'un bit de données.

+1, le protocole n'en est qu'au début, et plein de chose reste à optimiser.

Pourquoi ne pas simplement annuler l'action et envoyer un message au client ?

Car il vaut géré les actions en cascade (si grâce à ce truc il as utilisé l'objet pour gagner un combat, je fait quoi?). A cause du client qui continue de vivre sa vie sans attendre le serveur. En plus, je ne vois pas pourquoi faire ça quand c'est une triche flagrante.

Lib 3D ou 2D ?

Erreur de frappe, 2D.

Pour en revenir au sujet de base, as-tu finalement résolu ton problème initial ? Si oui, comment ?

J'ai pour l'instant fait avec des cast partout bien crade, et car ces derniers temps ma vie perso et pro me prenne beaucoup de temps. Mais j'essite encore entre template et utilisation.
Donc j'ai mes réponses.

[Ekleog]

D’après mon expérience et ce qu'ont m'as retourné. Il est fréquent d'avoir sur de courte période, un attroupement, lors des event organisé par les admins, pour gagner un objet unique. Ca regroupe fréquemment 50% du serveur. Aprés il y a des parades, j'ai mit un limite avec un hysteresis, pour ne plus afficher les joueurs de la map courante aprés une limite, et il y as d'autre algo. Mais ça reste des parades.

Pitié ! Je veux bien fermer les yeux la plupart du temps, mais là, j'ai mis deux minutes à comprendre la phrase. -> qu'on m'a, il est fréquent ; courtes périodes
Et puis, si il y a 50% du serveur, il peut être intéressant de mettre en place un système de démultiplication de la map courante : en quelque sorte, superposer la map avec elle-même, et un joueur arrivant dans la map se retroune dans une des instances superposées en round-robin. Si deux joueurs veulent se rejoindre, il faut bien sûr leur en donner l'occasion. Et, enfin, il faudrait que l'admin soit présent sur toutes les instances à la fois, bien sûr.
Mais, en tout cas, pour ce type de rassemblement, il faut s'attendre à un effondrement des performances.

Pour les hardcore gamer oui, car il y passe 16h par jour, et veulent pas ce faire pirater leur compte. Idem pour ceux qui utilise le même mot de pass partout. Théoriquement toutes les transmissions devrai être crypter, sans faire distinction de ce qui est important ou pas (ce qu'apporte l'ipv6 avec ipsec).
Après, ça reste facultatif.

pas se*
Après, pourquoi ne pas chiffrer l'authentification, et après valider l'emploi de la socket pour tel joueur ?
En même temps, oui, il est toujours mieux de chiffrer. Mais le coût du déchiffrement peut alourdir (encore !) la pile TCP/IP. (ipsec est implémentée directement dedans, non ?

C'est dans un cas très exterme, dans un cas + réaliste ça peu monter. Les personnes ont souvent 40~50Ko d'upload en pratique avec l'adsl. Et plus ont ce rapproche de cette limite, plus les données attendes leurs tour car d'autre données sont envoyé, et plus les latences explose (encore un argument pour minimiser/supprimer l'influence des latences).

Sauf qu'un utilisateur moyen utilise... Allez, 1kbps d'upload ? (Oui, les statistiques faites en vol.)
Du coup, même si tu arrives avec le serveur qui tourne à 100% avec 30Kbps, les performances du serveur même restent plus importantes que la bande passante.

Ce qui reste bien inférieure au temps de transmission, au temps d'une requête... et maintenant si je transmet 1Mo ou 1Ko, c'est pas le même temps à 50Ko/s...

Sauf que je croyais que la BP n'était pas la limite ?
Et puis, tu envoies souvent des paquets réductibles de 1Mo à 1ko ? Si oui, peut-être faudrait-il revoir le protcole, non ?

D'un autre coté, Qt ceux veux pas que une lib de GUI, donc qu'il fasse les choses correctement. Ce qui est suffisant (et si j'ai besoin de +, je peu le faire moi même ou utilisé une autres libs)

Qt ne se veut pas qu'une*
Après, je ne vois toujours Qt que comme un hippopotame obèse, donc mon jugement est probablement biaisé.

Car il vaut géré les actions en cascade (si grâce à ce truc il as utilisé l'objet pour gagner un combat, je fait quoi?). A cause du client qui continue de vivre sa vie sans attendre le serveur. En plus, je ne vois pas pourquoi faire ça quand c'est une triche flagrante.

il faut gérer*
Tu le rembobines jusqu'avant le moment où le serveur a repéré la triche.
Et puis, ce n'est pas forcément une triche flagrante, ça peut parfaitement être un défaut de l'ordinateur. (RAM défaillante, processeur over-overclocké...)

J'ai pour l'instant fait avec des cast partout bien crade, et car ces derniers temps ma vie perso et pro me prenne beaucoup de temps. Mais j'essite encore entre template et utilisation.
Donc j'ai mes réponses.

Du coup, pour te donner un dernier conseil (après il te faudra voir par toi-même), je te propose de séparer l'architecture en 3 parties :

• La partie commune, une lib externe. Contient entre autres Map* ; qui encapsule le comportement de base d'une map, et moveOnTheMap, fonction qui prend une Map, une direction et un pointeur sur une MovableEntity en paramètre. MovableEntity étant une classe de base à tout truc qui peut se déplacer, ou un truc du genre.
• La partie client : un exécutable. Est chargé de la GUI, des calculs client, et de la communication avec le serveur. Contient Player ; qui hérite de MovableEntity. Contient Map_client, qui hérite de Map. etc.
• La partie serveur : cf. partie client.
• Lors d'un jeu singleplayer, client et serveur sont lancés sur le même ordi. Lors d'un jeu multiplayer, ils sont simplement lancés sur deux ordis différents.

Avec ça, normalement, tu parviens à éviter toute duplication de code !

[alpha_one_x86]

Et puis, si il y a 50% du serveur, il peut être intéressant de mettre en place un système de démultiplication de la map courante : en quelque sorte, superposer la map avec elle-même, et un joueur arrivant dans la map se retroune dans une des instances superposées en round-robin. Si deux joueurs veulent se rejoindre, il faut bien sûr leur en donner l'occasion. Et, enfin, il faudrait que l'admin soit présent sur toutes les instances à la fois, bien sûr.
Mais, en tout cas, pour ce type de rassemblement, il faut s'attendre à un effondrement des performances.

Mon but c'est de le limiter. Moi j'avais pensé faire une zone de visibilité n'affichant que les 50 joueurs max (s’agrandissant et se réduisant en fonction). Bref, pas mal d'algo possible, et je doit bien prendre le temps d'y réfléchir.

Après, pourquoi ne pas chiffrer l'authentification, et après valider l'emploi de la socket pour tel joueur ?

Mes connaissances en cryptage doivent être trop limité, j'ai pas compris. Chiffrer juste l'authentication? Par facilité, car Qt me fourni soit non crypté, soit crypté, je pense pas avoir d'autre choix. Aprés c'est du détails, je veux pas perdre trop de temps la dessus.

En même temps, oui, il est toujours mieux de chiffrer. Mais le coût du déchiffrement peut alourdir (encore !) la pile TCP/IP. (ipsec est implémentée directement dedans, non ?

D’après ce que j'ai lu oui, mais avec les derniers cpu et l’encryptions matérielle, crypter est relativement peu coûteux comparer à la couche tcp/ip.

Sauf qu'un utilisateur moyen utilise... Allez, 1kbps d'upload ? (Oui, les statistiques faites en vol.)
Du coup, même si tu arrives avec le serveur qui tourne à 100% avec 30Kbps, les performances du serveur même restent plus importantes que la bande passante.

100% du cpu sur ma petite machine, c'est quand même + de 500 joueurs, et encore, sans optimisation en assembleur. Je pense que à ce niveau, la bande passante vas être déjà bien utilisé.
Après j'ai fait un algo où les joueurs ne ce vois pas entre eux, pour les serveurs ou les performances sont limite (trop de joueur, ou petit serveur).

Sauf que je croyais que la BP n'était pas la limite ?

Un benchmark ne reste qu'un benchmark, il teste les points que je veux, mais n'est pas représentatif. Alors la bande passante n'est pas le facteur limitant dans le bench (surtout du à tout les joueurs groupé au même endroit), mais ça ne veux pas dire que c'est toujours le cas.
Par contre coté serveur, on est limité à 10Go transmit par moi ou autre limitation sur les serveurs low-cost. Ou les bandes passante ce paie 150€/mois de plus

100 Mbps garantis pour le serveur +149.00€ HT /Mois (SOIT 178.20€ TTC)...
1 Gbps garanti pour le serveur +899.00€ HT /Mois (SOIT 1075.20€ TTC)

Il y as encore 1ans c'était comme dans les pays pauvres, 150€/mois pour juste 10Mbps de plus.
Après je suis dans un pays du tiers monde, avec chaque Ko qui ce paie et qui sont difficilement transmit. Je paie le smic d'ici chaque mois en internet pour juste avoir du 40Ko/s et 30Ko en upload... c'est 500€/mois pour avoir du 1Mbps en adsl.

Et puis, tu envoies souvent des paquets réductibles de 1Mo à 1ko ? Si oui, peut-être faudrait-il revoir le protcole, non ?

C'est pour certain point, je pense (peu important, fait que au début):
* Transmission de fichiers
* Synchronisation de la liste de fichiers du client
Mais plus important et non prévisible:
* Liste de déplacement des autres joueurs
* Messages chat trop long, ...

Après, je ne vois toujours Qt que comme un hippopotame obèse, donc mon jugement est probablement biaisé.

Il me facilite la programmation, aprés avec un profiler je peu optimiser, et si ça suffit pas, je change une partie en C pur.
Mon expérience c'est que Qt peu étre trés lourd par fois, mais le temps gagner à coder peu être ré-investi dans l’optimisation.

Tu le rembobines jusqu'avant le moment où le serveur a repéré la triche.

Ca veux dire garder l'xp, les objects, ... entre chaque action, si je considère 255 actions max, ça fait plusieurs méga facilement. Aprés faut retrouver à quel niveau restauré, ce qui n'est pas forcement l'action même, bref un gouffre de mémoire et de performance.

Et puis, ce n'est pas forcément une triche flagrante, ça peut parfaitement être un défaut de l'ordinateur. (RAM défaillante, processeur over-overclocké...)

Problème matériel, alors rien n’empêche d'envoyé des codes de protocole faux, corrompre l'application ou le datapack, ... après je ne peu rien y faire, et essayé de fixé ça coté serveur c'est une perte de temps.
Après, overclocking = horloge constante, donc le temps passe de la même manière, et si c'est l'horloge qui est foireuse que faire? Le remettre en permanence à ça place d'origine car il as été trop vite? Ou le permettre de courir à 200 à l'heure...?
Sérieusement, compenser les erreurs sont les pires choses à faire pour la sécurité, et en plus ça pourri le programme de code presque inutile... c'est comme si pour accédé à ton compte bancaire, si il te manque un numéro il te laisse passer. En plus l'interception de mot de passe est rare, par contre les bots de triches pour les mmorpg non.

[Ekleog]

Mes connaissances en cryptage doivent être trop limité, j'ai pas compris. Chiffrer juste l'authentication? Par facilité, car Qt me fourni soit non crypté, soit crypté, je pense pas avoir d'autre choix. Aprés c'est du détails, je veux pas perdre trop de temps la dessus.

Qt ne propose pas tout ce qu'il te faut.
Un système de "chiffrement" basique (et proposant une bonne sécurité) :
Un secret partagé entre client et serveur : le hash salé SHA-512 du mot de passe.
(J'espère que tu ne stockes pas le mot de passe en clair !)
Inscription : Utilisateur entre username & mot de passe. Dans l'idéal, on fait toutes les étapes suivantes en JS / côté client. On calcule hash = sha-512(username + password + [random chain]). On envoie au serveur [username, hash, [random chain]]. Le serveur stocke tout ça. (Ici est le point sensible de l'affaire : quelqu'un qui sniffe à ce moment pourra toujours s'identifier à la place de l'utilisateur, mais je ne vois pas comment faire mieux ; à part HTTPS ou une socket SSL ; justifiée à ce moment.)
Identification :

• Le client demande username, password à l'utilisateur ;
• Le client envoie l'username au serveur ;
• Le serveur répond [random chain] au client (toujours la même [random chain], hein) ;
• Le client calcule hash1 = sha512(username + password + [random chain]) ;
• (Partie plus sécurisée car bloquant une replay attack) Le serveur envoie [random chain 2] au client (qu'il vient juste de générer, qu'il ne stocke que pour la durée de la connexion) ;
• Le client calcule hash2 = sha512(hash1 + [random chain 2]) (il faudrait voir pour utiliser un hmac, mais ça risque d'être plus complexe à mettre en oeuvre) ;
• Le client envoie hash2 au serveur ;
• Le serveur calcule hashS = sha512(hash + [random chain 2]) (il récupère le hash dans sa BDD) ;
• Le serveur vérifie que hashS == hash2 (que son hash est bien le même que celui envoyé au client) ;
• Si OK, le serveur a bien une socket valide ;
• Si non, la socket est invalide. Rejeter la connexion (et décrémenter un compteur de mauvais essais / augmenter le délai de réponse, pour bloquer le brute-force ?).

L'avantage est qu'aucun chiffrement n'est nécessaire : seuls des hash temporaires et des valeurs aléatoires sont échangées.

Attention, il faudrait que tu vérifies le protocole : je peux parfaitement m'être trompé quelque part !
Mais, normalement, ça protège totalement l'intégralité de la connexion, sans même nécessiter de socket spéciale. La solution la plus simple pour pouvoir se connecter sur un compte autre resterait probablement l'exploitation d'une faille 0-day.

D’après ce que j'ai lu oui, mais avec les derniers cpu et l’encryptions matérielle, crypter est relativement peu coûteux comparer à la couche tcp/ip.

Sauf que ça alourdit encore la couche TCP/IP.
Et puis, je ne sais pas comment fonctionnent les sockets TCP de Qt, mais comment fait-il pour savoir que ce n'est pas un MITM ?

100% du cpu sur ma petite machine, c'est quand même + de 500 joueurs, et encore, sans optimisation en assembleur. Je pense que à ce niveau, la bande passante vas être déjà bien utilisé.

Sauf que tu dis que la BP à 10kbps (du serveur, je suppose) fait 100% du CPU.
Donc... fail ?
Et puis, tu dis "sans optimisation en assembleur". Pitié, n'en fais pas ! A moins de savoir *exactement* ce que tu fais, tu risques surtout de plomber complètement les performances.
Regardes d'abord le profiling. Si tu repères un bottleneck, observes l'algorithme employé. Si il n'y a aucun moyen de l'améliorer (unordered_map vs. map, etc.), alors réfléchis à l'occupation mémoire (moins de mémoire, moins de cpu... thx cache ! (Bon, après, faut pas aller chercher sur le DD tout le temps, sinon t'es mal, forcément.))
Et, une fois que tu as fait tout ça, si la fonction est toujours un bottleneck, tu peux aller observer le code assembleur généré et bien réfléchir si tu aurais vraiment fait mieux. Et si tu penses pouvoir faire mieux, penses à venir nous demander.
Mais n'oublies pas qu'"early optimization is the root of all evil" !

Après j'ai fait un algo où les joueurs ne ce vois pas entre eux, pour les serveurs ou les performances sont limite (trop de joueur, ou petit serveur).

Est-ce qu'on peut encore parler de MMO, alors ?

[...]
C'est pour certain point, je pense (peu important, fait que au début):
* Transmission de fichiers

Je peux comprendre ?

* Synchronisation de la liste de fichiers du client

bis.

Mais plus important et non prévisible:
* Liste de déplacement des autres joueurs
* Messages chat trop long, ...

Peut-être pourrait-il être intéressant de collecter des informations sur le serveur en prod, comme logger tous les paquets envoyés pendant un moment.
Après, ça te permettra de les compresser et de calculer le gain réel. Alors, là seulement, il pourra être envisageable de compresser. Toujours la même citation : "early optimization is the root of all evil". Surtout que tu ne connais pas encore vraiment les caractéristiques du serveur en prod'.
Et si tu stockes chaque déplacement sur 2 bits (4 directions, non ?), en moyenne les joueurs vont dans toutes les directions, donc je pense que sur ce point il y aura probablement très peu de gain.
Sur les messages chat, la compression est envisageable (beaucoup de redondances dans le langage commun), mais, alors, autant la faire côté client et le serveur ne relaie que des messages déjà compressés (et log les messages compressés aussi). Comme ça, tout le travail CPU est fait par le client.

Il me facilite la programmation, aprés avec un profiler je peu optimisé, et si ça suffit pas, je change une partie en C pur.

Je comprends qu'il peut simplifier. Mais, franchement, boost.asio >> Qt sockets ; SFML >> Qt 2D (encore que je n'aie pas testé ce dernier, mais bon...)...
Reste-t-il une autre utilisation de Qt que tu fasse ? (Si c'est pour faire une GUI non personnalisée, alors je veux bien. Mais un jeu avec une UI à la firefox, je vois mal, quoi.)

Mon expérience c'est que Qt peu étre trés lourd par fois, mais le temps gagner à codé peu être ré-investi dans l’optimisation.

Et utiliser une lib network potable, ça fait gagner autant de temps, voire plus (moins le temps perdu à en apprendre l'utilisation) ; et l'optimisation est moins nécessaire.

Ca veux dire garder l'xp, les objects, ... entre chaque action, si je considère 255 actions max, ça fait plusieurs méga facilement. Aprés faut retrouver à quel niveau restauré, ce qui n'est pas forcement l'actio)n même, bref un gouffre de mémoire et de performance.

Non ! Le serveur ne stocke que les actions qu'il connait, et qu'il a validé.
Du coup, à chaque fois que le serveur reçoit une action, il la valide (ou pas). Si il la valide, il update son état interne. Si il ne la valide pas, il ne l'update simplement pas et refuse l'action. C'est alors au client de se débrouiller pour revenir en arrière à l'état que lui renvoie le serveur (position, direction actuelle, état dans le combat, etc.), et d'en informer l'utilisateur.
Il me semble que c'est toujours mieux que de crasher.

Problème matériel, alors rien n’empêche d'envoyé des codes de protocole faux, corrompre l'application ou le datapack, ... après je ne peu rien y faire, et essayé de fixé ça coté serveur c'est une perte de temps.

Non, justement, inutile de fixer ça côté serveur.
Le serveur contient un état du joueur, le client aussi.
Si jamais il y a désynchronisation (pour raison ou pour une autre), le serveur renvoie un code d'erreur avec en bonus l'état où est le joueur selon lui. Le client n'a plus qu'à updater son état interne avec celui que lui envoie le serveur, et tout est bien qui finit bien.

Après, overclocking = horloge constante, donc le temps passe de la même manière, et si c'est l'horloge qui est foireuse que faire? Le remettre en permanence à ça place d'origine car il as été trop vite? Ou le permettre de courir à 200 à l'heure...?

Parce que tu bases ta vitesse de personnage sur la vitesse processeur ?

Il me semble qu'on ne se comprend pas, là.

Si l'utilisateur tente bien de courir à 200 à l'heure, oui, le serveur va sans arrêt le remettre à la place où il a le droit d'être à la vitesse normale. Mais ça nécessiterait une modification du client.

Sérieusement, compenser les erreurs sont les pires choses à faire pour la sécurité,

Hein ?

et en plus ça pourri le programme de code presque inutile...

Sauf que c'est juste envoyer un paquet au lieu de fermer la connexion, hein. Et ajouter un handler basique pour le paquet, bien sûr ; mais ça se résume à un code presque plus simple que le déplacement.

c'est comme si pour accédé à ton compte bancaire, si il te manque un numéro il te laisse passer.

Pas du tout. C'est simplement éviter de faire crasher ton navigateur web à chaque fois que tu te plantes dans ton code.

En plus l'interception de mot de passe est rare, par contre les bots de triches pour les mmorpg non.

De toute façon, avec ta technique de coupure de la connexion, tu ne bloqueras pas les bots, hein.
Il faudra trouver des techniques bien plus sophistiquées (timing des paquets, etc.).
Il est probable que la chasse au bot prendra à peine moins de CPU que tout le reste du serveur.

[alpha_one_x86]

(J'espère que tu ne stockes pas le mot de passe en clair !)

Les hash (en SHA-1), j'ai vu pire...

Et puis, je ne sais pas comment fonctionnent les sockets TCP de Qt, mais comment fait-il pour savoir que ce n'est pas un MITM ?

Aucune idée, c'est pour ça que les socket QSslSocket de Qt me semble plus plus sécurisé.
Après je doit rafraîchir mes connaissances sur le sujet.

Donc... fail ?

Oui, bench biaisé, les bots ne font que marché, sans utilisé le chat, ni combattre, ...
Donc dans certaines conditions c'est le cpu limitant, dans d'autre condition non.

Et puis, tu dis "sans optimisation en assembleur". Pitié, n'en fais pas ! A moins de savoir *exactement* ce que tu fais, tu risques surtout de plomber complètement les performances.

Je ne compte pas en faire, j'ai pas le niveau, et faire de l'assembleur de merde vas être pire (comme tu le dit justement).

Bon, après, faut pas aller chercher sur le DD tout le temps, sinon t'es mal, forcément.

Ce je connait bien, grâce à mon copieur de fichier. Tout est chargé au début, les accès disque sont dans un thread, et rien n'est synchrone. Donc je peu envoyé le datapack en continue car c'est que ça qui accède au disque.

Et, une fois que tu as fait tout ça, si la fonction est toujours un bottleneck, tu peux aller observer le code assembleur généré et bien réfléchir si tu aurais vraiment fait mieux. Et si tu penses pouvoir faire mieux, penses à venir nous demander.

J'ai justement bien profiler, j'ai des complexité linéaire/fix, partout, avec de bonne optimisation, c'est juste sur l'envoie des déplacements sur les autres joueurs que ça monte vite (complexité carré).

Mais n'oublies pas qu'"early optimization is the root of all evil" !

Par contre optimiser dès le départ en bien structurant le code, et fessant quelque profiling pour ce rendre compte de comment marche la base, ou sont les lenteurs, comment les isolés, ... Ça m'as toujours réussi. Je profile régulièrement, par contre rien de poussé avant d'avoir presque fini les fonctionnalités.

Est-ce qu'on peut encore parler de MMO, alors?

Par contre tout le reste marche, surtout que les mouvements, c'est des données à traités en continue, le reste non (complexité linéaire occasionnellement utilisé et les lenteurs ne sont pas trop gênantes). C'est au pire: 5 pas par secondes par joueur à envoyé sur les autres joueurs... et les demandes d'échange/combat c'est une fois toute les 10minutes entre 2 joueurs...
Pour moi, ça perds tout son fun. Car contre ça permet d'étre adapté à tout les cas: Embarqué, serveur ARM low-cost, pas de consomation de bande passante pour ça, ...
J'estime que les déplacements vont être responsable de 90% de l'utilisation du cpu, 60% de l'upload et 25% du download coté serveur. Car forcément, un jeu du type que je fait, ont passe beaucoup de temps à se déplacer. Mais mes estimations sont peu être fausse.

Je peux comprendre ?

Le client synchronise sont datapack locale sur celui du serveur. C'est pour les éléments majoritairement static.
Donc le client fait la même chose qu'un rsync, envoie de la liste de fichier qu'il as, le serveur il réponds les fichiers à gardé, ceux à supprimé, et ceux à mettre à jour.

Peut-être pourrait-il être intéressant de collecter des informations sur le serveur en prod, comme logger tous les paquets envoyés pendant un moment.
Après, ça te permettra de les compresser et de calculer le gain réel. Alors, là seulement, il pourra être envisageable de compresser. Toujours la même citation : "early optimization is the root of all evil". Surtout que tu ne connais pas encore vraiment les caractéristiques du serveur en prod'.

Voila

Et si tu stockes chaque déplacement sur 2 bits (4 directions, non ?), en moyenne les joueurs vont dans toutes les directions, donc je pense que sur ce point il y aura probablement très peu de gain.

Je part du principe que les joueurs font en moyenne 2 pas avant de changer de direction. J'envois 1Byte pour le nombre de pas fait, et 1Bytes pour la nouvelle direction prise. Et les clients font avancé les autres joueurs dans la direction qu'il ont prise. (Biensur avec une syncro quand de nouvelle info arrive).

Je comprends qu'il peut simplifier. Mais, franchement, boost.asio >> Qt sockets ; SFML >> Qt 2D (encore que je n'aie pas testé ce dernier, mais bon...)...
Reste-t-il une autre utilisation de Qt que tu fasse ? (Si c'est pour faire une GUI non personnalisée, alors je veux bien. Mais un jeu avec une UI à la firefox, je vois mal, quoi.)

Après je peu changer simplement, je doit justement voir quel lib utilisé, ou, comment... par exemple QML2 avec Qt5 me permet une gestion des animations, sans que j'ai à changer les trames avec un timer... Il supporte aussi les widgets (liste, bouton, input, ...). D'autre lib sont peu étre mieux pour le client comme pour le serveur. Mais je le fait dans le langage que je connait, comme ça au lieu de perdre du temps à apprendre et avoir un jeu qui ne sortira jamais, j'avance. Une grosse fonctionnalité qui me le fait fortement préféré coté serveur, c'est les threads et les signaux/slots (event) avec Qt. Ca me permet de ne jamais bloquer sur les packet à complexité fixe et qui doivent étre traité rapidement, et de faire ça sur toutes les plateformes sans toucher à la boucle d’évènements.

Et utiliser une lib network potable, ça fait gagner autant de temps, voire plus (moins le temps perdu à en apprendre l'utilisation) ; et l'optimisation est moins nécessaire.

Comme tu l'as dit, faut l'apprendre, et j'ai pas autant de temps que ça. (Ultracopier me prends du temps, en plus de ce projet).

Non ! Le serveur ne stocke que les actions qu'il connait, et qu'il a validé.
Du coup, à chaque fois que le serveur reçoit une action, il la valide (ou pas). Si il la valide, il update son état interne. Si il ne la valide pas, il ne l'update simplement pas et refuse l'action. C'est alors au client de se débrouiller pour revenir en arrière à l'état que lui renvoie le serveur (position, direction actuelle, état dans le combat, etc.), et d'en informer l'utilisateur.

Voila, ça fait un truc plus complexe coté client... je préfère le géré de façon + intelligente coté client (mettre les objets visibles mais non utilisable tant que le serveur n'as pas validé).
Et si il marche sur les murs... je le remet à sa place et ont en parle plus? Idem si il essaye d'avoir un max d'argent, ... si ça marcher comme ça, le pirate peu essayer toutes les failles sans être embêté, et l'admin n'en ai jamais informé.

Il me semble que c'est toujours mieux que de crasher.

Pour les applications oui, pour les serveurs non car tu pénalise tout les autres clients.

Si jamais il y a désynchronisation (pour raison ou pour une autre), le serveur renvoie un code d'erreur avec en bonus l'état où est le joueur selon lui. Le client n'a plus qu'à updater son état interne avec celui que lui envoie le serveur, et tout est bien qui finit bien.

Le client n'est pas de confiance, c'est uniquement le serveur qui l'est... mais je comprends le principe.

Sauf que c'est juste envoyer un paquet au lieu de fermer la connexion, hein. Et ajouter un handler basique pour le paquet, bien sûr ; mais ça se résume à un code presque plus simple que le déplacement.

Ça veux dire re-synchronisé le client partiellement ou totalement, ... je préfère le re-connecter dans un 1er temps. Ça implique faire quitter/venir dans un combat, la position, l'inventaire, ...

De toute façon, avec ta technique de coupure de la connexion, tu ne bloqueras pas les bots, hein.
Il faudra trouver des techniques bien plus sophistiquées (timing des paquets, etc.).
Il est probable que la chasse au bot prendra à peine moins de CPU que tout le reste du serveur.

Coupure + anti brute force + login que toutes les minutes, ... mais l'important c'est qu'il coupe et qu'il post sur le chat un message pour tout le monde, pour dire que le compte XXXXX à été couper pour possible piratage.
Ca force aussi le client à ne pas envoyé des conneries, et au dev du client d’être coupé avec une erreur qui n'est pas silencieuse.

[Ekleog]

Aucune idée, c'est pour ça que les socket QSslSocket de Qt me semble plus plus sécurisé.
Après je doit rafraîchir mes connaissances sur le sujet.

En fait, soit elles requièrent un certificat SSL valide (peu probable), et alors il faut en payer un ; soit il faut les informer de la clef publique du serveur. Ce cas est plus probable.
Mais là, ça va être compliqué, si tu veux pouvoir monter plus d'un serveur. Ou alors créer une CA ? Complexe aussi.
En même temps, il n'est pas forcément nécessaire de sortir carrément du SSL.

Oui, bench biaisé, les bots ne font que marché, sans utilisé le chat, ni combattre, ...
Donc dans certaines conditions c'est le cpu limitant, dans d'autre condition non.

Ah, d'accord.
Après, il faudrait que tes bots agissent vraiment aléatoirement, style balancer des messages aléatoires sur le chat à des intervalles de temps aléatoires, et trucs du genre.
Comme ça, ça serait plus réaliste.
Et vu que ça modifiera l'utilisation du cache, il est possible que ça fasse encore ralentir le serveur, même si la complexité asymptotique descend.

J'ai justement bien profiler, j'ai des complexité linéaire/fix, partout, avec de bonne optimisation, c'est juste sur l'envoie des déplacements sur les autres joueurs que ça monte vite (complexité carré).

Donc il faut (probablement) trouver un moyen d'optimiser ça. Enfin, je vois que tu y travailles, donc tout va bien.

Par contre optimiser dès le départ en bien structurant le code, et fessant quelque profiling pour ce rendre compte de comment marche la base, ou sont les lenteurs, comment les isolés, ... Ça m'as toujours réussi. Je profile régulièrement, par contre rien de poussé avant d'avoir presque fini les fonctionnalités.

faisant*
Sinon, +1.

Le client synchronise sont datapack locale sur celui du serveur. C'est pour les éléments majoritairement static.
Donc le client fait la même chose qu'un rsync, envoie de la liste de fichier qu'il as, le serveur il réponds les fichiers à gardé, ceux à supprimé, et ceux à mettre à jour.

Mais ce n'est pas le protocole de jeu en soi, plutôt celui de l'updater.
Du coup, oui, ces données ont intérêt à être compressées. Après, le serveur n'a aucun calcul à faire dessus : il peut tout pré-compresser.
Mais le reste, inutile.

Je part du principe que les joueurs font en moyenne 2 pas avant de changer de direction. J'envois 1Byte pour le nombre de pas fait, et 1Bytes pour la nouvelle direction prise. Et les clients font avancé les autres joueurs dans la direction qu'il ont prise. (Biensur avec une syncro quand de nouvelle info arrive).

Je penses que tu sous-estimes le nombre de 2 pas, hein.

Après je peu changer simplement, je doit justement voir quel lib utilisé, ou, comment... par exemple QML2 avec Qt5 me permet une gestion des animations, sans que j'ai à changer les trames avec un timer... Il supporte aussi les widgets (liste, bouton, input, ...). D'autre lib sont peu étre mieux pour le client comme pour le serveur. Mais je le fait dans le langage que je connait, comme ça au lieu de perdre du temps à apprendre et avoir un jeu qui ne sortira jamais, j'avance. Une grosse fonctionnalité qui me le fait fortement préféré coté serveur, c'est les threads et les signaux/slots (event) avec Qt. Ca me permet de ne jamais bloquer sur les packet à complexité fixe et qui doivent étre traité rapidement, et de faire ça sur toutes les Voila

Côté serveur particulièrement, je conseillerais d'éviter l'hippopotame !
boost.thread ; boost.signal ; boost.asio ... tout ça sera plus fonctionnel, en plus de ne pas nécessiter de changer la toolchain de compilation.

Voila, ça fait un truc plus complexe coté client... je préfère le géré de façon + intelligente coté client (mettre les objets visibles mais non utilisable tant que le serveur n'as pas validé).
Et si il marche sur les murs... je le remet à sa place et ont en parle plus? Idem si il essaye d'avoir un max d'argent, ... si ça marcher comme ça, le pirate peu essayer toutes les failles sans être embêté, et l'admin n'en ai jamais informé.

Exactement !
A la limite, tu peux conserver côté serveur un compteur nbFail ; et arrivé à 3 (avec une recharge de 1 par heure), il est déco/ban tmp et l'admin est mailé, ou un truc du genre.

Pour les applications oui, pour les serveurs non car tu pénalise tout les autres clients.

L'autre client est content de voir ton serveur crasher ? Et puis, tu n'as rien à perdre à donner une chance au client de se rattraper.

Le client n'est pas de confiance, c'est uniquement le serveur qui l'est... mais je comprends le principe.

Sauf que le serveur ne prend, bien sûr, en compte aucun paquet venant du client qui soit invalide !

Ça veux dire re-synchronisé le client partiellement ou totalement, ... je préfère le re-connecter dans un 1er temps. Ça implique faire quitter/venir dans un combat, la position, l'inventaire, ...

Ca implique simplement un state = packet.state.

Coupure + anti brute force + login que toutes les minutes, ... mais l'important c'est qu'il coupe et qu'il post sur le chat un message pour tout le monde, pour dire que le compte XXXXX à été couper pour possible piratage.
Ca force aussi le client à ne pas envoyé des conneries, et au dev du client d’être coupé avec une erreur qui n'est pas silencieuse.

=> Pas compris le rapport avec un bot.

[alpha_one_x86]

En fait, soit elles requièrent un certificat SSL valide (peu probable), et alors il faut en payer un ; soit il faut les informer de la clef publique du serveur. Ce cas est plus probable.
Mais là, ça va être compliqué, si tu veux pouvoir monter plus d'un serveur. Ou alors créer une CA ? Complexe aussi.
En même temps, il n'est pas forcément nécessaire de sortir carrément du SSL.

Ou certificat auto signé, et ceux qui veulent, il mettrons un certification qu'il auront payé. Et d'autre en non crypté.

Mais ce n'est pas le protocole de jeu en soi, plutôt celui de l'updater.
Du coup, oui, ces données ont intérêt à être compressées. Après, le serveur n'a aucun calcul à faire dessus : il peut tout pré-compresser.
Mais le reste, inutile.

La c'est le travail du programme pour le datapack, c'est dans une optique de serveur libre (ont met l'ip du serveur qu'on veux). Par contre updater pour le programme pour windows/mac, et linux c'est à la distro de faire sont travail.
Après faut que je vois comment implémenté ça, comment bien faire la compression, ...

Je penses que tu sous-estimes le nombre de 2 pas, hein.

Minimum, pas moyen. Moi j'en fait 10/15 avant de changer de direction.

=> Pas compris le rapport avec un bot.

On peu ensuite utiliser coté OS le firewall pour limiter le nombre de connexion secondes. Mod limite et recent d'iptable.
Quand le piratage est fait à la main, le nombre de packet foireux est faible.


Tu as une différence de performance entre Qt et boost, ou sont les chiffres? Surtout coté réseau et signals/slots.
Car ça veux dire tout refaire (déjà 300Ko), apprendre. Et j'utilise pas mal Qt (Qt xml, réseau, QHash/QMap, ...). Coté serveur je propose ce dernier en GUI ou un CLI.

[alpha_one_x86]

J'ai déjà regarder pour passé à boost plusieurs fois. Surtout le coté performance m’intéresse pour le serveur.

Par contre, pour la partie 2D du client, je reste sur l'idée d'avoir quelque chose de simple que je puisse maintenir. Car c'est surement quelqu'un d'autre qui vas le faire, et je doit pouvoir le maintenir (freelance).

[Ekleog]

Ou certificat auto signé, et ceux qui veulent, il mettrons un certification qu'il auront payé. Et d'autre en non crypté.

Sauf qu'un certif auto signé, il est totalement inutile, et ultra facile à forger pour un MitM, quoi.
Du coup, faut intégrer le certificat dans l'exécutable. Ce qui est au bas mot complexe.

Tu as une différence de performance entre Qt et boost, ou sont les chiffres? Surtout coté réseau et signals/slots.
Car ça veux dire tout refaire (déjà 300Ko), apprendre. Et j'utilise pas mal Qt (Qt xml, réseau, QHash/QMap, ...). Coté serveur je propose ce dernier en GUI ou un CLI.

Je n'ai pas de chiffres sous la main.
Par contre, il me semble me souvenir que boost était plus rapide, entre autres grâce au fait que ce n'est pas un pachyderme.
Après, mon jugement est biaisé : Qt "fournissant" aussi de la GUI, je me sens obligé de le détester : pour moi on fait une chose et on le fait bien. Avec boost, tu ne paies que ce que tu utilises. IIRC, avec Qt tu paies quasiment pour tout.
Et si je me souviens bien, boost.asio est une des biblios réseau les plus vantées. Après, ça fait un moment que je n'ai plus recherché de trucs dessus, donc bon...

J'ai déjà regarder pour passé à boost plusieurs fois. Surtout le coté performance m’intéresse pour le serveur.

Par contre, pour la partie 2D du client, je reste sur l'idée d'avoir quelque chose de simple que je puisse maintenir. Car c'est surement quelqu'un d'autre qui vas le faire, et je doit pouvoir le maintenir (freelance).

Sauf que ça serait plus simple de découper le boulot en modules, et plus maintenable :

• Un module réseau -> utilise boost.asio
• Un module UI -> SFML ou autre
• Un module [je ne vois pas quoi ajouter d'autre... gestion du cache et des accès disque ? calculs ?]

Après, tu as un module principal qui glue tout ça, et c'est facile de maintenir.

[alpha_one_x86]

J'ai ouvert un topic pour quel que question, je viens à peine de finir la conception préliminaire du protocole et de la forme de communication. J'ai même pas encore fait les trames:
http://www.developpez.net/forums/d12...server-mmorpg/

Sauf qu'un certif auto signé, il est totalement inutile, et ultra facile à forger pour un MitM, quoi.
Du coup, faut intégrer le certificat dans l'exécutable. Ce qui est au bas mot complexe.

Relativement facile avec la gestion de ressources de Qt, mais ça change pas grands chose, car avec un peu de sténo, on peu l'extraire.

Sauf que ça serait plus simple de découper le boulot en modules, et plus maintenable :

• Un module réseau -> utilise boost.asio
• Un module UI -> SFML ou autre
• Un module [je ne vois pas quoi ajouter d'autre... gestion du cache et des accès disque ? calculs ?]

Après, tu as un module principal qui glue tout ça, et c'est facile de maintenir.

Pour l'instant c'est le découpage de Qt. Par contre, le principe de bien s'organisé, oui je suis d'accords.
Après grâce à la loie de moore, je préfère resté sur ce que je connait si c'est juste pour gagné 30% de performance avec boost sur réseau + event. Je note que boost utilise epoll qui est très efficace. Donc passage serai pour les events/threads/réseau.
De toute façon j'utiliserai surement boost tot ou tard, faut juste que je m'y habitue.

[Ekleog]

Relativement facile avec la gestion de ressources de Qt, mais ça change pas grands chose, car avec un peu de sténo, on peu l'extraire.

En même temps tu n'inclus que le certif public, hein.
Si Qt te demande de mettre aussi la clef privée dans le programme client, il y a franchement un souci, quoi.

Après grâce à la loie de moore, je préfère resté sur ce que je connait si c'est juste pour gagné 30% de performance avec boost sur réseau + event. Je note que boost utilise epoll qui est très efficace. Donc passage serai pour les events/threads/réseau.
De toute façon j'utiliserai surement boost tot ou tard, faut juste que je m'y habitue.

Si tu me cites la loi de Moore, je ne peux pas ne pas citer la loi de Wirth. (cf. wikipedia pour plus d'infos)
Dans tous les cas, boost peut être utilisé dans tous les projets (en plus c'est quasiment que du header only, donc même pas de DLL supplémentaire à distribuer, ni d'options de compilation à modifier) ; et a donc cet avantage d'être générique.
Le jour où quelqu'un utilisera une lib Qt sans utiliser la partie graphique, on pourra m'appeler...

Et puis, en te baladant dans la doc, tu découvriras certains outils merveilleux. Dont, entre autres, asio.

[alpha_one_x86]

la loi de Wirth

Je viens d'apprendre ce que c'est... merci de m'avoir passé l'info c'est justement la loi qui résume ma vision de l'évolution de la majorité de logiciel.

EDIT: Voila aussi les chiffres que j'ai dans les mains, et que j'ai pas pu vérifier:
En moyenne les mmoprg officiels comme wow sont à moins de 5000 joueurs par serveur, et moi j'en tiens 100 000 sur un petit serveur. Et il me manque les resources utilisé des autres serveur pour 100 joueurs, ...