Application Winsock gérant plusieurs clients

Bon, depuis ma dernière application Winsock en console, j'ai éveolué. En effet vous m'avez grandement aidé. Maintenant, mon programme contient à la fois le client et le serveur, il est en API windows, il est non-bloquant, et il devrait gérer plusieurs client. Là je dirais bien devrais, car c'est là mon problème. Bon, certains doivent dire : "Ah ! Celui-là il va chialer sur le forum à chaque fois qu'il va avoir un problème !" Eh bien non. C'est que l``a, un peu comme avec mon autre problème, ça fait des jours que j'essai de tout faire pour régler le problème et rien n'y fait. Donc, comme le projet est en plusieurs fichiers, j'ai mis la source sur le site. Voici l'adresse : http://www.cppfrance.com/code.aspx?id=24506. Une fois de plus, j'apprécierai grandement votre aide. Merci d'avance.

Je viens de regarder vite fait ta source, mais il ne me semble pas avoir vu de traces de mutithreading...or ds ce type d'applications client/serveur (si jne me trompe pas), il est necéssaire de gerer chaque client par un thread different et pas faire de boucles comme tu l'as fait (si j'ai bien vu ds ta source). Si tu as besoin d'aide sur le mutithreading, renseigne toi sur _beginthread() sur MSDN, mais n'hesite pas a me demander malgré que je connaisse mal les threads..

Voila (au dodo maintenant)

++

Alhexman

Tu crois vraiment que ça soit nécessaire. Je veux bien te croire parce que je n'y connais absolument rien. C'est juste que selon ce que j'ai vu ailleurs ce n'est pas nécessaire. Mais s'il le faut, je vais utiliser les threads. Merci.

Enfin, dans ma logique a moi, ca me semble necessaire, mais ne te lance pas ds des travaux considerables (les thread c chiant a mettre en place) et attend demain pour avoir l'avis d'autres personnes...

Bonne nui

Salut,
Non non surtout pas un thread par client. C'est la pire des solutions niveau performances.
Pour ce genre de petit programme de chat, le modêle WSAAsyncSelect() est parfait.

Bon j'ai regardé rapidement j'ai noté quelques trucs:
- il faut appeler WSAAsyncSelect(...) apres bind, listen (cas serveur) ou apres connect (cas client).

- le socket d'ecoute est en mode WSAsyncSelect, donc les sockets retournés par accept(...) aussi. Inutile de rapeller WSAAsyncSelect(...) sur ces sockets.

- Lors de la reception d'un evenement FD_READ, il ne faut pas faire une boucle de recv sur tout les clients! il faut identifier quel est le client qui a envoyé des données et n'appeler recv() que pour ce client. Pour info, lors de la reception de FD_READ, lParam est le socket qui est concerné. Il suffit donc de comparer lParam
a ton tableau de socket pour savoir quel est le client qui a envoyé les données.

- La fonction Client.GetData() retourne un pointeur sur une variable déclarée dans la fonction (Data): cette variable est automatiquement détruite des que la fonction retourne, ca risque de poser des problemes.

- je te conseille de gerer l'event FD_CLOSE au moins du coté serveur pour tenir un tableau de socket client a jour.

la suite demain!

Wow merci je vais essayer ça tout de suite et je t'en donne des nouvelle. Merci beaucoup.

Par contre, je ne comprends pas comment utiliser lParam. Est-ce que c'est un index pour mes clients ( ce qui m'étonnerait ), ou si je le converti en socket en mettant (SOCKET) avant ça donne un socket valide, ou c'est autre chose. Merci.

Salut,
Exactement, lParam contient le socket qui est concerné par l'event FD_READ, c'est a dire le socket d'un de tes clients.

Pour recevoir les données de ce client, tu peux appeler directement recv en passant lParam en socket.

recv((SOCKET)lParam, ...);

Je ne suis pas sûr. Premièrement cette technique ne fonctionne pas me donnant une erreur selon laquelle j'utilise un socket non existant. Et deuxièmement j'ai tester avec des MessageBox la valeur de ceci, et ça donne toujours 1. Mais je te crois. Il faut croire qu'une fois de plus, je m'y prend mal. J'ai pourtant fait exactement ce que tu dis. :(

Salut,
Je me suis trompé, c'est wParam qui contient le socket, désolé.

lParam est utilisé pour le message de notification (LOWORD) et pour le message d'erreur (HIWORD).
Comme tu n'avais pas d'erreur et que tu recevais FD_READ (qui est defini a 1 dans winsock2.h), lParam contenait toujours 1.