Discussion :

[reacen]

Salut tout le monde, je suis débutant en Java (j'ai les bases, je programme en plusieurs langages) et j'ai un serveur (Multi-thread, tcp) qui reçoit environs à peu après 900 Joueurs de connectés simultanément.

Tout va bien, le serveur supporte ça très bien (Sur une machine 64bits assez puissante) mais j'ai remarquer qu'au bout de quelques heurs après avoir lancer le serveur, souvent (très souvent) cette fonction finit par mettre trop de temps pour répondre et terminer. Cette fonction (send()) est la fonction qui réponds les joueurs (envoie les packets), c'est à dire la fonction la plus appelé, donc j'aimerais qu'elle soit optimisé le plus possible:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public static void send(Personnage player, String packet)
{
	if(player.get_compte() == null) return;
	if(player.get_compte().getGameThread() == null) return;
	PrintWriter out = player.get_compte().getGameThread().get_out();
	if(out != null && !packet.equals("") && !packet.equals(""+(char)0x00))
	{
		packet = CrypterManager.toUtf(packet);
		out.print((packet)+(char)0x00);
		out.flush();
	}
}

Ce que j'ai remarquer après plusieurs tentative de débug du temps de réponses, c'est que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

out.print((packet)+(char)0x00);

Et surtout surtout cette partie:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

out.flush();

Mets trop de temps ! Des fois ça mets 6 secondes, des fois sa met 100 secondes, des fois 600, etc, je capte pas D'où peut venir le problème ? Comment corriger ça? Pourtant mon serveur (Windows) dépasse pas 10% de l'utilisation de son processeur! Besoin d’explications et d'idée merci.

[reacen]

Quelqu'un a peut être une idée du problème s'il vous plait?

[thelvin]

Mais justement, là c'est sûrement pas une question de processeur, mais de communication réseau -_-°.

Après, pourquoi elle met autant de temps j'en sais rien, je sais pas ce que c'est, moi, ton getGameThread().get_out() .

Par exemple, on peut supposer que tu ne fermes jamais la connexion avec les clients. Ce qui fait que s'ils perdent la connexion pendant qu'ils jouent, toute tentative de communication avec eux sera impossible et durera indéfiniment (ou du moins jusqu'à ce qu'un timeout quelconque interrompe la tentative.)
Ce n'est qu'une possibilité parmi tant d'autres. Les réseaux c'est pas de la gnognotte.

[reacen]

Merci thelvin pour ta réponse, le problème parait plus logique maintenant. Tu as peut être raison.

Pour le getGameThread().get_out(). C'est une method qui retourne ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public PrintWriter get_out() {
	return _out;
}
 
// Et le _out vient d'un truc comme ça:
_out = new PrintWriter(_socket.getOutputStream());

Comment pourrais-je faire pour tester ton idée, et vérifier si le (la) socket est vivant et connecté avant d'envoyer ?

Est-ce que cette nouvelle ligne de code devrait suffire pour corriger le problème à ton avis?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if (!_socket.isConnected()) return;

[reacen]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (!_socket.isConnected()) return;

ça ne répare toujours pas mon problème

Peut être que c'est due au nombre de threads? Car j'alloue à chaque joueur connécté son propre thread. ça peut être ça la cause? 900 threads?

Tout ce que je cherche c'est un moyen de pousser le: out.flush() (ou .print()) à ne pas dépasser ~500 Millisecondes. Car sinon le serveur commence à lagger pour un rien...

[Elendhil]

Le problème ne vient surement pas des 900 threads (quoi que ^^) mais bon la faut vraiment arrêter , faut que tu reprennes absolument le code de ton serveur , il faut pas utiliser un thread par client. Il faut que tu utilises un pool de threads , et aussi passe au package nio , ne reste pas sur le package io pour un serveur de jeu.

Cette ligne me parait vraiment bizar :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
player.get_compte().getGameThread().get_out();

C'est quoi la logique de fonctionnement derrière getGameThread() ?

[reacen]

Le problème ne vient surement pas des 900 threads (quoi que ^^) mais bon la faut vraiment arrêter , faut que tu reprennes absolument le code de ton serveur , il faut pas utiliser un thread par client. Il faut que tu utilises un pool de threads , et aussi passe au package nio , ne reste pas sur le package io pour un serveur de jeu.

Cette ligne me parait vraiment bizar :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
player.get_compte().getGameThread().get_out();

C'est quoi la logique de fonctionnement derrière getGameThread() ?

Merci pour ton conseil, mais je ne peux pas actuellement basculer en thread pooling, puisqu'il faudra des années pour recoder le serveur en entier. Le serveur étant un très grand projet open-source, travaillé par plusieurs personnes, j'ai décider de l'améliorer à ma façon. (De toutes façons à part ce problème actuelle, je trouve que thread/par client est impeccable)

Pour la ligne de code que vous n'avez pas compris Elendhil, c'est très simple. Chaque joueur a son propre thread. (la class getGameThread Runnable) qui gère les événements lorsqu'il reçoit les packets etc. Cette classe contient le thread, ainsi que le socket du joueur, son compte, et son personnage, et ses informations...

le get_out() dans getGameThread() retourne un "PrintWriter" du getOutputStream() du socket, qui permet d'écrire sur le socket plus facilement à ce qu'il parait.

Le serveur supporte jusqu'à 1500 joueurs connectés sans vraiment aucun problème! Mais après quelques heurs il commence à mettre du temps pour envoyer et flush le socket. Je ne comprends vraiment pas pourquoi.


Dans le jeu il y a un canal public où tout les connéctés se parlent entre eux.
Le principe est simple, tu dis "Salut", et le serveur l'envoie à tous les joueurs connectés. (grace à la fonction send(Personnage player, String packet) plus haut).

Mais quand le serveur envoie le mot "Salut" à tout le monde, il finit par tomber sur une personne qui son socket RAM (ou je sais pas quoi)! donc il va attendre le _out.flush de cette personne pour des minutes, ce qui fait ce thread plante. Et le joueur qui a parler en canal public peut plus rien faire pendant des minutes... (entre 5000 milliseconde à 3 ou 4minutes, des fois plus)

Mais pourquoiiiiiiiii ???


Ya pas un moyen pour limiter le _out.flush() ou _out.print() pour que, si il va dépasser 1Seconde, lui dire de quitter?

J'espère qu'on me comprends au moins?

[tchize_]

Ok, si je suis la logique.

Le joueur 1 envoie salut
salut arrive coté serveur, traité par thread1
thread1 va aller chercher lui même les socket de thread2 et de thread3 et utiliser le writer pour y écrire salut a destination des joueur2 et joueur3?

Si c'est le cas, prépare toi à relever tes manches, ca ne peux qu'échouer tôt ou tard. Les socket, les PrintWriter et les OutputStream ne sont pas multithread safe. Avant d'écrire quoi que ce soit dans ces socket il faut s'assurer qu'aucune autre thread ne peut le faire en même temps, via la mise en place de verrous.

ET si, 900 thread, c'est beaucoup (pas impossible, mais beaucoup). Ne t'attends pas à pouvoir monter ultérieurement à 10.000 joueurs avec cet architecture Il faut savoir qu'en 64 bits, par exemple, un thread java dispose d'une stack de 1M par défaut. Donc 900 threads =900M occupés .... On peux réduire cette valeur (paramètre xss) mais alors on réduit d'autant la profondeur d'appel possible.

Pour ce qui est du flush qui prend du temps, si la socket est "morte" coté client, aucun moyen de le savoir coté server avant un timeout. Hors, si t'as beaucoup de données à flusher, la fin ne pourra pas partir tant que le début n'aura pas été validé. -> le flush attends le timeout au final. Peux-tu confirmer qu'après ce "long" temps d'attente, tu obtiens une exception?

[Elendhil]

Rien à ajouter , tchize est un expert.

[HS]

Merci pour ton conseil, mais je ne peux pas actuellement basculer en thread pooling, puisqu'il faudra des années pour recoder le serveur en entier. Le serveur étant un très grand projet open-source, travaillé par plusieurs personnes, j'ai décider de l'améliorer à ma façon. (De toutes façons à part ce problème actuelle, je trouve que thread/par client est impeccable)

Dans ce cas tu devrais utiliser reddwarf server , tu ne mettras pas des mois à migrer ton jeu. Cela va drôlement te simplifier la vie , tu seras plus obligé de coder dans un environnement multi-threads , avec l'obligation de la gestion des verrous , ect ... .

Cela ce présente comme un serveur d'application (genre tomcat, glassfish ) mais conçu pour le jeu vidéo. Donc c'est comme si tu développais ton serveur mais tu fais abstraction de toute la partie réseau, muti-threading, persistance des données en te concentrant uniquement sur la logique de jeu. Une fois ton application développé , tu le place dans reddwarf server.

Le projet a été développé par Sun donc ce n'est pas juste un projet amateur, avec le rachat de sun , oracle a abandonné son développement , l'équipe qui travaillait dessus continue à son amélioration. C'est open source et tu peux l'utiliser dans un projet commercial sans problème.

Un Jeu sur facebook édité par une société l'utilise , ils ont obtenu un pic à 5000 utilisateurs simultanés , et ils estiment que le serveur était à 50% de charge.

Tu auras toutes les infos ici :

http://www.reddwarfserver.org/?q=con...aming-universe

Maintenant à toi de voir si tu préfères passer des heures dans le débugging multi-threads, la conception/architecture d'un serveur de jeu ou alors de te concentrer sur l'avancement de ton jeu en lui même sans te prendre la tête avec ces problèmes annexes.
[/HS]

[Logan Mauzaize]

900 threads ça sert à rien, je suis sûr qu'en faisant du profiling l'application passent plus de temps en WAIT qu'à travailler.

Pour la notification, je la ferais dans un thread à part, et je règlerai le timeout sur une période courte.
Il faudrait peut-être également parallélisé l'ensemble des envois de données.

Sinon utiliser l'UDP plutôt que TCP. En général les jeux ça marche comme du streaming, l'envoie de données est continue.

[tchize_]

+1 pour l'udp si possible (j'ai déjà codé dans des jeux ou c'était impossible de passer en udp facilement).

Et je rejoint aussi les avis pour réduire le nombre de threads. "Normalement", tu devrais avoir ceci comme logique:

une liste de socket.
Une "queue de messages à envoyer". Avec un certains nombre de threads qui traitent cette queue. chaque thread list un message de la queue et l'envoie vers la socket qui lui est destinée.
Une "queue de lecteur" avec aussi un certain nombre de threads qui passent sur les socket une à une voir si il y a des données à lire, les lisent et les stockent dans l'objet joueur
Un ou plusieurs threads "jeu" qui parcours les joueurs en continue et regarde ce qu'il y a a faire.


Il y a déjà en java de base tout ce qu'il faut pour créer des queue de taches, queues gérées par un pool de threads. A mon avis c'est une bonne voie à suivre.

[Logan Mauzaize]

J'aurais pas dit mieux !

[Elendhil]

En général l'udp est à éviter pour les jeux vidéos mise appart pour les fps et peut-être certains rts.

Là à mon avis avec 900 utilisateurs sur le serveur c'est sur que c'est ni un fps , ni rts. Je pense plus pour un dofus like ^^.

Par exemples les derniers gros mmorpg comme guild wars , wow , utilise le protocole tcp pour les communications.

[Logan Mauzaize]

Et vois la latence que ça donne alors que sur CS

[Elendhil]

Bah pour ce genre de jeux une latence de 250 ms , n'est absolument pas grave.
Pour CS ça pose problème !

D’ailleurs le monsieur il trouvait qu'une latence de 500 ms , c'étais bien ^^.

[tchize_]

tout dépend de l'application visée.

Le TCP implique un charge plus importante sur le noyaux du serveur, des risques de blocages à l'écriture (ici le cas du flush) et des risque de délais parfois conséquents pour le client.

D'un autre coté, l'UDP implique de mettre en place un protocole tolérant un pourcentage de paquets perdus, donc une certaines redondance dans les données. Il implique aussi des contraintes sur les tailles de paquets que n'a pas TCP, car les paquets udp trpo gros peuvent être droppé alors qu'en TCP on les coupe.

[Elendhil]

Dis moi si je me trompe.

Mais avec udp il y a pas moyen de savoir si ton client est encore connecté au serveur ? Donc si on utilise pas une connexion en tcp en plus , de l’émission de paquets en udp , comment peut on faire un jeux en ligne ?

Ou alors considérer que quand on reçois pas un paquet tous les X temps , le client n'est plus connecté , mais ça semble pas très fiable vu que des paquets peuvent se perdre.

De plus les jeux en ligne où la latence est primordial sont rare quand même, les jeux facebook , les jeux web/tableau/formulaire(genre ogame,travian , ect ..),les mmorpg quand tu regardes leurs gameplay , la latence est loin d'être le facteur le plus important , la fiabilité des communications importe plus.

Peut-être pour la partie pvp des mmo (qui ont un gameplay très nerveux) cela peut être intéressant de l'utiliser en plus d'une connexion tcp.

Donc c'est ce que je disais à part pour un fps , du rts , ou des partie lans , l'udp me semble pas indispensable , et apportera plus de complications qu'autres choses.

[tchize_]

Ou alors considérer que quand on reçois pas un paquet tous les X temps , le client n'est plus connecté , mais ça semble pas très fiable vu que des paquets peuvent se perdre.

Si pendant 10 secondes TOUS les paquets du client ont disparus, et si le client est supposé envoyer 10 paquets par secondes, on peux décement
supposé qu'il y a interruption réseau

[Elendhil]

Si pendant 10 secondes TOUS les paquets du client ont disparus, et si le client est supposé envoyer 10 paquets par secondes, on peux décement
supposé qu'il y a interruption réseau

Hmm c'est ce que doit faire quake live (quake 3 dans le navigateur), il était impossible de jouer en wifi avec son portable, on était constamment déconnecté.

Bon tu me diras qu'elle idée de jouer à quake avec le wifi ^^.

[Logan Mauzaize]

Dis moi si je me trompe.

Moi

Mais avec udp il y a pas moyen de savoir si ton client est encore connecté au serveur ? Donc si on utilise pas une connexion en tcp en plus , de l’émission de paquets en udp , comment peut on faire un jeux en ligne ?

De la même manière que quand tu pars en timeout avec TCP !

Ou alors considérer que quand on reçois pas un paquet tous les X temps , le client n'est plus connecté , mais ça semble pas très fiable vu que des paquets peuvent se perdre.

Autant qu'avec TCP.

Comme dit Tchize_ le problème majeur me semble être la taille des datagramme ...