Merci pour tes explications Yamashi

Par contre j'imagine que la programmation réseau doit prendre beaucoup beaucoup de temps. Et au final pour un petit projet c'est surement plus intéressant d'utiliser une telle librairie, pour pouvoir se concentrer sur une autre parti du projet.
Et si au final elle est vraiment complète ca permet de la garder si le projet deviens vraiment sérieux. Enfin il y a quand même des avantages quoi :p

Hardcpp par contre soit j'ai pas comprit ta phrase soit je sais pas... Mais il y a des projets commerciaux qui utilisent Raknet ! Des studio comme Epic Games, NetDevil, Codemaster, etc.. l'utilisent.
Après c'est vrai que c'est une licence "Creative Commons" donc si tu veux faire du commercial ben tu paye.

Dernière modification par nikska (06-01-2009 21:59:56)

yamashi :

...
Mais mon architecture est bien plus complexe que ca car j'utilise le load balancing donc je fais passé mes paquet a la bonne machine qui renvoie la réponse a envoyer... Puis j'ai fais en sorte que mon serveur ne puisse pas planter car il s'auto récupère si il y a un cycle qui saute ou une erreur dans la mémoire...

Désolé j'arrive un peu tard sur ce topic et ma question est peut-être un peu hors-sujet, mais quel algo de load balancing utilises-tu?
Je suis pas trop doué en réseau, mais c'est un sujet qui m'intéresse.

valholl

Je ne pense pas qu'il existe vraiment "d'algo" de load balancing.
Je découpe la carte en zone et je test dans quel zone est le joueur puis je forward au serveur de la zone et si le joueur a un angles de vue sur d'autres zone il est aussi forward vers les autres zones.

Et au final pour un petit projet c'est surement plus intéressant d'utiliser une telle librairie, pour pouvoir se concentrer sur une autre parti du projet.

Si tu es seul je suis entièrement d'accord mais en équipe par exemple mon collègue est codeur client et moi codeur serveur, il vaut mieu utiliser les API car tu n'as que ca a faire (facon de parler) et pour les raisons (cf plus haut)...

yamashi :

Je ne pense pas qu'il existe vraiment "d'algo" de load balancing.
Je découpe la carte en zone et je test dans quel zone est le joueur puis je forward au serveur de la zone et si le joueur a un angles de vue sur d'autres zone il est aussi forward vers les autres zones.

Je me demande comment sont gérés les problèmes d'overload, de recovery et de proportions dynamiques de charge (entres autres) dans ce cas.

valholl

les problèmes d'overload, de recovery et de proportions dynamiques de charge (entres autres) dans ce cas.

Dans le cas ou un serveur serait surpeuplé (a partir de 5000 joueurs dans la zone ce qui n'arrivera sûrement jamais), le node principal demanderas a chaque serveur non peuplé de prendre une partie de la région surpeuplé et son node voisin prendra en charge la zone libéré...
Mais d'ici 2010 quand le jeu sortira nous aurons surement près de 100 core par serveur avec 30go de ram je ne pense pas que ce genre de problème puisse intervenir.
Pour ce qui est du recovery les serveurs ne peuvent pas planter sauf sous une coupure de courant donc je n'ai pas a me soucier de ca.

yamashi :

Mais d'ici 2010 quand le jeu sortira nous aurons surement près de 100 core par serveur avec 30go de ram je ne pense pas que ce genre de problème puisse intervenir.
Pour ce qui est du recovery les serveurs ne peuvent pas planter sauf sous une coupure de courant donc je n'ai pas a me soucier de ca.

Pour le recovery je parlais "recovery en cas de surcharge", pas en cas de problème d'update DB.

Pour info je travaille sur des stations Sun Fire T2000, qui ont 16Go de RAM et un CPU UltraSPARC T1 avec 32 CoolThreads en exécution simultanée (4 core émulant 8 thread) - c'est du petit matériel en fait - et le problème se présente car ça n'a rien à voir avec l'optimisation du code ou le matériel seuls, c'est un problème lié aux réseaux quels qu'ils soient.

En pratique, on modélise la charge serveur et réseau en fonction de ce qu'on attend.  Ensuite on configure des algos (balance de charge à proportions dnamiques, controle de charge adaptif basé sur système de monitoring avec courbe de régulation dynamique en proportionnel intégral) pour coller à ce modèle théorique, puis l'algo s'adapte de manière automatique en fonction de ce qui est observé.

C'est une façon de faire, mais quand on travaille sur des serveurs qui reçoivent une charge distribuée le problème de balance comme de régulation va se présenter.  Si le serveur se plante ou surcharge, quelle est le temps de recovery si on ne peut pas basculer (surcharge globale par exemple)?  Et de switchover?  Si le serveur est surchargé, comment déplacer sa charge (en optimisant les destinataires) sans sous-charger ce serveur?  Au vu du cout d'un serveur, comment assurer que l'usage est optimal sans controle et distribution de charge?  Pourquoi ne pas refuser certaines connexions plutot que de vouloir à tout prix les gérer?

Je pense que quand on développe sur plusieurs serveurs, ces problèmes doivent être pris en compte.  Les process industriels existent (PI, PID, etc.), de plus ils sont simples à mettre en oeuvre, par exemple:
- un système de distribution de charge qui monitore les serveurs de DB et distribue en fonction de la charge monitorée sur chaque serveur DB, donc dont les proportions sont dynamiques puisque la charge sur chaque serveur peut varier indépendamment des autres
- une modélisation de serveur avec charge à courbe dynamique et refus d'envoi à un serveur si celui-ci est surchargé + rebalance)

Et puis, si ça n'était pas nécessaire, je serais au chômage depuis longtemps   Je pense en développer une lib pour gérer ça dans le projet ALODP d'ailleurs...  Car tabler sur le seul matériel est une mauvaise idée à mon sens.

yamashi :

Dans le cas ou un serveur serait surpeuplé (a partir de 5000 joueurs dans la zone ce qui n'arrivera sûrement jamais)

Tu as fait des stress-tests?  Dire que ça n'arrivera jamais c'est une erreur, dans les systèmes à charge aléatoire tu ne peux pas le calculer, tout ce qu'on peut faire c'est des modèles théoriques et c'est pour ça justement qu'on utilise des régulateurs adaptifs rapides afin d'éviter que la destination n'explose.  Et si même ta charge était uniforme et synchronisée, ça ne serait pas mieux (peut-être même pire).  Evidemment, pour les serveurs Web on ne fait pas attention à ça puisque c'est du "best effort", si le serveur est down tant pis. Mais du best effort pour un jeu réseau en ligne je trouve ça moyen.

Tu proposes de redistribuer, c'est bien, mais pas suffisant à mon avis.

valholl

Dernière modification par valholl (08-01-2009 10:07:58)

Oui j'ai fais des stress test, le système n'est pas a charge aléatoire comme tu le penses car les zones sont définit de manière statique au départ et oui j'ai penser a faire des zones plus petite que d'autre car je sais a peu près qu'elle zone seront peuplés et lesquels ne le seront pas.
Etant donné que le serveur ne run rien a part une node je ne calcul plus en processus car ca fait des instructions inutiles alors que les benchmarks ont déjà était fait...
Pour ce qui est du recovery je ne vois pas de cas possible pour que cela arrive, a moins que plus de 60 000 joueurs se connectent il n'y aura aucun problème de surcharge de plus la surcharge réseau je ne pas y faire grand chose car c'est au niveau hardware pas software, si il n'y a plus de bande passante on accepte plus de joueurs c'est aussi simple que ca et on attend que les joueurs quittent... pour réaccepter quand il n'y a plus de problème hardware ou bande passante.
Mais la je suis plus dans de la recherche pur qu'autres chose car je n'avais jamais vraiment travailler sur du multi node qui communique par réseau...
Mais bon pour le moment ca fonctionne très bien donc pas je m'en fiche un peu que ce ne soit pas conforme a ton standard...

Oui j'ai fais des stress test, le système n'est pas a charge aléatoire comme tu le penses car les zones sont définit de manière statique au départ et oui j'ai penser a faire des zones plus petite que d'autre car je sais a peu près qu'elle zone seront peuplés et lesquels ne le seront pas.

Des zones plus petites que d'autres? Oui ça me semble une bonne idée.
Ce que je disais par aléatoire c'est que le nombre de joueurs par zone n'est pas connu de manière absolue.
Cela aurait été une bonne idée de rendre les zones dynamiques en fonction du nombre réel de joueurs, ça évite les mauvaises surprises (et on sait que la théorie et la pratique...), en ce qui me concerne je ferais comme ça (mais ce n'est que mon avis bien entendu, ne nous méprenons pas).

de plus la surcharge réseau je ne pas y faire grand chose car c'est au niveau hardware pas software, si il n'y a plus de bande passante on accepte plus de joueurs c'est aussi simple que ca et on attend que les joueurs quittent... pour réaccepter quand il n'y a plus de problème hardware ou bande passante.

Justement, c'est le principe du load control: éviter la surcharge avec un mécanisme prédictif.  Evidemment refuser des joueurs tout simplement c'est facile, mais la surcharge n'aurait-elle pas un impact sur les joueurs déjà connectés?  Quel est le seuil maximum de charge autorisée?
De par le fait que tu acceptes plus de connexions, tes réponses ajoutent de la charge, et pour éviter ça on ajoute une couche intermédaire qui sert de tampon régulateur, si un joueur demande à se connecter on le refuse même que le serveur derrière n'est pas surchargé mais plutôt à une limite de traitement qu'on sait qui permet aux joueurs déjà connectés de ne pas subir de pertes de connexion.

Dans le cadre des telecoms refuser quelqu'un qui appelle un numéro d'urgence ce n'est pas permis, par contre un numéro gratuit oui, c'est pour ça qu'on fait du load balancing; donc si par exemple suite à un accident grave les centrales sont surchargées d'appel, on doit baisser le trafic sur d'auters lignes moins critiques comme des 0800.  Evidemment les joueurs ne sont pas aussi critiques qu'un appel à une ambulance, mais pour ceux qui sont connectés ça risque de se faire sentir.  Bien entendu, si le seuil est maintenu bas, cela peut tenir, mais bon, ne jamais tabler sur le hardware...

Mais bon pour le moment ca fonctionne très bien donc pas je m'en fiche un peu que ce ne soit pas conforme a ton standard...

Ce n'est pas mon standard, c'est une manière de faire utilisée dans l'industrie et ce à de multiples niveaux et dans de multiples disciplines.  Mais comme à la base tu avais parlé de load balancing, j'étais curieux de savoir ce qui était utilisé... j'imaginais plutot que les serveurs se distribuaient la charge à coups d'algorithmes, mais donc si je comprends bien c'est géré au niveau zone et pas serveur.

Pour finir, si je peux me permettre cette petite correction: quand tu disais 'Je ne pense pas qu'il existe vraiment "d'algo" de load balancing', dans ton jeu visiblement c'est le cas, mais dans l'industrie, si, ça existe (que ceux intéressés par ce genre d'algorithmes se manifestent).

valholl