Discussion :

[GoldenEye]

Bonjour à tous
Je travaille actuellement à l'élaboration d'un jeu 3D en C++.
Simplifions en disant qu'il s'agit d'une sorte de bataille navale à N joueurs
J'ai un vrai souci vis à vis des sockets winsock qui permettent de gérer les aspects réseaux (TCP, recv non bloquants)

a) En effet, le process principal (le main) est géré par GlutMainLoop()
b) Parallèlement en mode Server, un Thread de priorité THREAD_PRIORITY_BELOW_NORMAL permet de gérer l'attente des connexions TCP

Code :

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

1
2
3
4
5
6
 
while(1)
{
  if(accept(premier_slot_disponible))
     ...
}

c) Dès que la première connexion est enregistrée, un thread de priorité THREAD_PRIORITY_BELOW_NORMAL permet côté Serveur de faire des receive non bloquants sur tous les slots réseau libres

Code :

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

1
2
3
4
5
6
7
8
9
10
 
while(1)
{
   for(int i = 0 ; i < nbConnectes ; i++)
   {
      recv(slot[i],buffer);
      if(strlen(buffer) != 0)
                Redispatch(i,buffer) // renvoie l'info à tous les clients
   }
}

d) Côté client, deux threads priorité THREAD_PRIORITY_BELOW_NORMAL gèrent
- l'envoi des messages

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
while(1)
{
  switch(dataToSend)
  {
  case CHAT:
     send(server,...)
     break;
  case UNITY_MOVED:
     send(server,...)
  break;
  default:;
}

-la réception des messages

Code :

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

1
2
3
4
5
6
7
 
while(1)    
{
    recv(socket, buffer)
    if(strlen(buffer)) 
       Traitement(buffer);
}

L'ensemble marche bien mais les traitements réseaux sont très lents. Lorsque je teste 1 ou 2 instances de l'exe sur la même machine, en réseau local (127.0.0.1), plusieurs secondes peuvent passer entre l'envoi de la donnée depuis un client (un texte de chat par exemple) et son affichage sur les autres clients
Si j'augmente la priorité des threads, c'est l'OpenGL qui devient subitement plus lent et le nombre de fps diminue.
Que faire, que changer dans le moteur réseau ?
Merci d'avance

[loufoque]

recv(slot[i],buffer);
if(strlen(buffer) != 0)

recv prend 4 arguments.
Appliquer strlen ici est non seulement inutile, mais devrait aussi provoquer des erreurs de segmentation de temps en temps.

[GoldenEye]

Je sais bien que recv prend 4 arguments... Sinon je n'aurais pas précisé que le programme marche :-) C'est juste pour simplifier la lisibilité du code posté que j'ai volontairement squizzé les éléments non essentiels
En revanche pour le strlen() > 1 (et non zéro), que proposes-tu d'autre ? Sachant qu'à l'issue du traitement du message un memset à "" est réalisé et que buffer est un char[256].
Merci

[loufoque]

recv renvoie le nombre d'octets lus.

[Emmanuel Delahaye]

En revanche pour le strlen() > 1 (et non zéro), que proposes-tu de moins stupide ? Sachant qu'à l'issue du traitement du message un memset à "" est réalisé et que buffer est un char[256].

Un memset(), c'est pas gratuit.

http://emmanuel-delahaye.developpez....eaux.htm#texte

[dragonjoker59]

Déjà comme dit loufoque, recv renvoit le nombre d'octets lus, donc pas besoin de tester la taille du buffer.
Je me demandais, pourquoi tu mets tes thread en THREAD_PRIORITY_BELOW_NORMAL?

[GoldenEye]

Merci les chefs, j'ai viré le strlen et le memset et c'est effectivement bien plus performant
Si je mets une priorité supérieure, l'OpenGL perd trop en fps et en fluidité
Merci encore

[nicroman]

Moi déjà ... je comprends pas tu fonctionnes en "non-bloquants"....
Et c'est pas un strlen/memset à chaque reception d'un paquet qui devrait diminuer ton frame-rate !!!
Je dirai même au contraire, si le jeu est "temps-reel réseau", la priorité des threads de gestion de réseau devrait être plus élevée que le reste... l'affichage (comme le son par exemple), n'est qu'accessoire au bon déroulement d'une partie !

Code :

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

1
2
3
4
5
6
 
while(1)    
{
    if (recv(socket, buffer)>0) 
       Traitement(buffer);
}

Ca c'est horrible (et ca va manger tout un core CPU à priori)...
D'ailleurs, à priori, si tu mets le socket en mode bloquant ca fera *exactement* le même résultat...


Coté serveur, on a le même probleme....
Utilises la fonction select pour choisir d'être "reveillé" quand un des sockets a reçu des données...

[screetch]

passe juste tes sockets en bloquant.....

et mets tes threads avec priorites maximales - 1. Ils sont sensés etre tout le temps en train de dormir, en attendant des données. donc passes tes sockets en bloquantes et attends que quelque chose se passe, ne mets pas des threads qui vont bouffer du CPU en permanence.