RV2931
Messages postés185Date d'inscriptionsamedi 21 mai 2005StatutMembreDernière intervention16 juillet 2016
-
18 mai 2006 à 12:41
cs_max12
Messages postés1491Date d'inscriptiondimanche 19 novembre 2000StatutModérateurDernière intervention 7 juillet 2014
-
19 mai 2006 à 07:21
Bonjour,
Je suis en train d'essayer de faire un chat en réseau, chaque machine est client/serveur sur un port. Mais on m'a conseillé de faire un thread client pour envoyer les message, et un thread serveur pour les recevoir et gérer les autres messages du genre "demande de connection de l'adresse xxx.xxx.xxx.xxx", enfin bon, ça c la structure que j'ai adopté, c p'tet pas la meilleur mais je le voyais comme ça...
Je connais le multithread, mais ce que je ne vois pas trop, c'est ce que je doit mettre dans chaque thread. Pour moi, je vois que chaque thread doit traiter les messages venant du socket ( READ WRITE, CONNECT...), mais je vois pas trop comment faire en sorte que ces thread reçoivent les messages. Le thread est en fait une nouvelle fonction de traitement de message, sauf qu'un thread, il a des arguements fixes à sa création, donc ????
En écrivant, ce message, j'ai régardé un peu mon code, et j'ai vu, que c'est WSAAsyncSelect qui permet de dire quel est le handle qui recevera les messages.
Un handle, c'est un handle sur un objet, hors une fonction n'est pas un objet, sauf si c'est un thread.?.?.?.? Sauf que le thread, je ne crois qu'il puissent recevoir de message système vu son prototype, enfin je ne sais pas, si qqu'un peut m'aider...
cs_max12
Messages postés1491Date d'inscriptiondimanche 19 novembre 2000StatutModérateurDernière intervention 7 juillet 2014 19 mai 2006 à 07:21
Tu n'aura pas besoin de WSAAsyncSelect pour les évènement de thread, seulemet recv est correct, si receive est égal à 0 ou -1, alors le socket à fait un close, le connect c'est a la création du thread ... je sais pas si tu sais ou je veux en venir.
void ClientThread(ClientArbre *Client)
{
char Buffer[1024+1]; //Avec le caractère 0
//À l'ouverture du socket
while (1)
{
Val = recv(Client->Sock, Buffer, 1024, 0);
if (Val <= 0)
break; //Le close
//ICI TU TRAITE LES DONNÉES !!
}
//Ici le code pour socket quand il est fermée
}
C'est le code d'un thread pour l'exemple. Mais attention ! Si tu utilise une liste chainée il faudra bien sûr utiliser la synchronisation (CriticalSection ou WaitForSingle etc ...) pour éviter qu'un thread veulent accèder à un élément ayant été détruit mais sans que la liste ait été mise à jour. Enfin c'est seulement pour éclaicir un peu ma pensée.
Sur ce je te donne un e-book gracieuseté de Brunews, tu y trouvera la méthode des blocking-socket et plein d'autre :
http://vbaddons.free.fr/reseaulivre.zip
cs_max12
Messages postés1491Date d'inscriptiondimanche 19 novembre 2000StatutModérateurDernière intervention 7 juillet 2014 18 mai 2006 à 17:17
Tu peux aussi créer un thread par client côté serveur et recevoir les messages avec recv (qui est autoblocant donc parfait pour un thread et un boucle infinie). Chaque thread va s'occuper de chacun des clients de façons indépendante et en paramètre à la création du thread tu peux passer un pointeur qui pointera vers une structure qui contiendra les informations spécifiques à chaque client, par exemple dans mon cas j'utililse une liste chainée et je passe l'adresse du maillons de la chaine en argument. Ceci permet de pouvoir parcourir facilement les clients par la suite si on veut faire interragir chaques clients.
RV2931
Messages postés185Date d'inscriptionsamedi 21 mai 2005StatutMembreDernière intervention16 juillet 2016 18 mai 2006 à 17:27
ouay, aussi,
mais je vois toujours pas comment envoyer les messages système du socket sur chacun des threads ???
je vois par la fonction WINAPY, et WndProc, là ok;
je vois toujours les notions de sous-classement pour le traitement des messages directement par un objet et pas par la fenêtre, j'en utilise,
mais comment l'appliqué à un thread ????
parce que ça implique que tu ouvre un serveur dans le thread, mais je vois pas comment les messages evènementiels du socket arrivent au thread, ou alors c le thread principal qui les gère, et qui recrée des évenement de synchronisation du genre CreateEvent.... WaitForSingleObject(hEventReadContact1); ????
L'idée me semble faisable, mais est-ce déontoligiquement dans les règle de programmation de socket en multi-thread ?