WINSOCK SERVEUR MULTI-CLIENT / CLIENT SURCHARGÉ
Sharkiller
Messages postés
71
Date d'inscription
dimanche 12 octobre 2003
Statut
Membre
Dernière intervention
9 janvier 2009
-
2 nov. 2007 à 13:08
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 - 5 nov. 2007 à 13:17
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 - 5 nov. 2007 à 13:17
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44586-winsock-serveur-multi-client-client-surcharge
https://codes-sources.commentcamarche.net/source/44586-winsock-serveur-multi-client-client-surcharge
5 nov. 2007 à 13:17
3 nov. 2007 à 16:56
- Le code, bien que 'fonctionnel', n'est pas une amélioration de ce qui existe déjà à des dizaines d'exemplaires sur le site. Voir règlement.
- Si, tu utilises un nouveau contrôle côté serveur à chaque itération puisque tu incrémente l'index d'un composant que tu charges
- Ok pour les ports, mais tu ne parles que du port de connexion au serveur, le fameux port ouvert par ton admin réseau. Or, il faut savoir que :
- ton client, lui aussi, utilise un port pour sortir de la machine. Ce port est géré en automatique par le système (dans ton cas car tu ne le gères pas) = un nouveau port à chaque connexion
- Côté serveur, quand il reçoit une demande de connexion sur LE port ouvert, il charge un nouveau composant et lui assigne cette connexion. Ce nouveau port utilise, à son tour, un nouveau port de connexion, cette fois sortante, pour répondre au client = un nouveau port à chaque connexion en plus du port d'écoute.
- Ton choix d'ouvrir et de fermer une succession de sockets n'est pas un choix technique viable. Aucun serveur digne de ce nom ne peut t'imposer cela. Tu as surement une autre idée derrière la tête, mais laquelle ...
- En te répondant, nous t'offons de fiabiliser ton application et te faire comprendre (bien qu'on ne soit pas en classe) les subtilités des sockets.
Si tu restes sur ton idée d'origine, libre à toi, mais ne t'étonne pas si elle merdouille.
3 nov. 2007 à 08:30
Un petit commentaire quand même :
- le code EST fonctionnel aussi bien le serveur que le client
- je n'utilise PAS un nouveau controle à chaque lancement
- je ne peux pas utiliser d'autres ports car l'environment est loudrement sécurisée et l'admin reseau à du être convaincue d'ouvrir quelques ports seulement. Il est hors de question que j'en ai plus a dispo.
- comme je marque dans Descritpion/Solution je pourrais en effet laisser la connexion ouvert, mais dans la vraie application client ce ne serait pas souhaitable. Il faut que je (ou quelqu'un) trouve la solution pour l'application "exemple" telle qu'elle est là.
par contre en effet il serait intéressant que je vérifie l'evolution de l'utilisation de la machine :).
Merci pour le lien des limitations, j'y jetterais un coup d'oeil.
Je reste sur mon point de vue que ça doit être un soucis de 'nettoyage' sous windows soit matériellement sur la carte reseau.... il faut juste trouver pourquoi le pc ne sait pas avaler autant d'ouvertures et de fermetures.
merci :)
3 nov. 2007 à 02:51
Dans le réglement, on demande de ne déposer que les sources fonctionnelle.
Il n'est pas habituel qu'on y dépose des sources à dépanner.
Pour une fois, on la laisse mais envoie moi un mot privé avec l'adresse de cette page afin que je la supprime.
Parmi les limitations de VB6 ( http://www.vbfrance.com/codes/LIMITATIONS-VB6_35122.aspx ), il y a le nombre de composants, de l'ordre de 250.
Avec ta technique de création d'une nouvelle connexion à chaque paquet, tu arrives vite à saturation. D'ailleurs, si tu regardes évoluer l'utilisation mémoire de ton application dans le gestionnaire des tâches, tu verras surement un chiffre grossir et grossir.
Il faut :
- soit que utilises toujours le même socket pour tout envoyer : déplace simplement le DoConnect avant le For
- soit tu modifies ton serveur pour qu'il réutiliser les index des winsocks déchargés et que son état est déconnecté.
De plus, quand un client lance une connexion, il utilise un port, choisi aléatoirement. Un port différent à chaque fois. On ne dispose 'que' de 65535 ports. Là, ta boucle ne fait que 8000 itérations, mais penses-y, ça peut gèner plus tard.
2 nov. 2007 à 15:38
C'est comme si le client avait besoin le temps d'avaler toutes ces ouvertures et fermetures de winsock.
Toutes les environ 3960 ouvertures rapidement l'un derrière l'autre il bloque pendant quelques minutes.
2 nov. 2007 à 14:52
Après ton erreur d'"adresse en utilisation", il renvoit depuis le début ou juste ce qu'il manque?
2 nov. 2007 à 14:24
Je voulais pas chercher d'alternatives, juste trouver le pourquoi et y rémédier
merci.
2 nov. 2007 à 13:36
2 nov. 2007 à 13:32
Non, non , les données sont justement bien reçues séparément (la preuve dans le fichier texte DATA).
Comme j'ai expliqué dans "solution" si je ne me déconnecte pas l'envoi se fais en 1 fois (fallait juste encore programmer pour qu'il envoi en morceaux de 4k ou 8k je pense puis c'était bon).
Seulement, le client peut lancer des opérations qui affectent plusieurs milliers d'enregistrements, tout comme il n'en peut qu'affecter qu'un seul des éléments....
Donc je voudrais faire fonctionner le petit programme "telle que".
2 nov. 2007 à 13:08
Que d'autres m'indiquent si je me trompe, mais je crois que quand on envoi des données en boucle via Winsock, les données sont toutes envoyées en même temps...
Cela impliquerait un regroupement des données reçues, et sûrement que la taille des données envoyées est limitée...
Combien "pèsent" tes lignes Brosske?