WINSOCK + : WINSOCK AMÉLIORÉ (ÉTABLI DES CONNEXIONS CRYPTÉES)
cs_Jack
Messages postés14006Date d'inscriptionsamedi 29 décembre 2001StatutModérateurDernière intervention28 août 2015
-
24 oct. 2003 à 12:03
cs_Delirium
Messages postés30Date d'inscriptionvendredi 11 octobre 2002StatutMembreDernière intervention 3 mai 2004
-
22 août 2004 à 22:17
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_Delirium
Messages postés30Date d'inscriptionvendredi 11 octobre 2002StatutMembreDernière intervention 3 mai 2004 22 août 2004 à 22:17
a la limite tu met un DoEvents et sa marche très bien pour pas fusionner des paquets
gabchampagne
Messages postés216Date d'inscriptionmercredi 2 avril 2003StatutMembreDernière intervention 5 mai 2004 24 oct. 2003 à 20:12
mais la liste d'attente évite d'avoir a diviser les paquets. Si tu fais un chat et qu'une personne envoie un texte avec des CRLF, ils seront divisez eux aussi. Pi ca évite de surcharger la mémoire. Les commentaires, c pas mon fort. Je vais corriger des bugs et ja vais ajouter des fonctions comme l'établissement d'une connexion cryptée. Pi quand je parle de stabilité, je parle au sujet des évènements connect et close qui se déclenchent desfois pas sur mon ordi.QUOI! tu dis que mon TCP marche pas, je ne suis pas un tweet. J'AI TESTÉ MA SOURCE AVANT. ca marche bien. Il y a juste une petit erreur dans le code de la timer dans le programme d'exemple (corrigé). P.S. pour entendre les erreurs, il faut ce fier à l'évènement error de mon CTRL. Pi qu'est ce que tu pense de ma facon de gérer les tags? Il va y avoir bien des modifications.
cs_polm
Messages postés26Date d'inscriptionjeudi 1 mai 2003StatutMembreDernière intervention21 novembre 2003 24 oct. 2003 à 17:33
moi je suis ton supporter!!!
cs_Jack
Messages postés14006Date d'inscriptionsamedi 29 décembre 2001StatutModérateurDernière intervention28 août 201579 24 oct. 2003 à 13:38
Je reviens donc, après avoir regardé ton code :
- Déjà, on ne perd pas de temps à lire les commentaires ... il n'y en a pas : pas facile de découvrir à quoi peut bien servir telle ou telle fonction, ou même à savoir ce que viens faire la collection dans le projet, ou encore ce que viennent faire les modules d'encodage64 ...
- Et ... ça bug : Pour le TCP, si tu fais un "Envoyer" sans avoir précédemment le serveur en éEcoute", le texte n'est pas envoyé, ça c'est normal, mais, même si tu passes le serveur en "Ecoute", il ne reçoit pas les textes suivants !
- Tu parlais de stabilité des winsocket : Tu utilises l'OCX Winsocks dans ton controle ! Alors, quel intérêt ?
- Etant donné que tu as simplifié les commandes (je crois que s'est le but de ton appli, en fait), le composant Serveur ne peut communiquer qu'avec un seul client puisque tu fais un "Accept RequestID" sur le serveur en écoute. --> Faudra revoir la structure même du contrôle si tu veux pouvoir l'utiliser en multiclients.
La prochaine fois que tu fais un user control et que tu veux pouvoir le tester dans une appli, je te conseille ceci :
- Crée un projet pour ton controle utilisateur, et un second projet dans lequel tu voudras insérer le controle.
- Regroupe ces deux projets au sein d'un groupe de projet
Avec ça, tu t'apercevra vite que quelques anomalies notamment, celle là :
Si tu compiles ton user control, et que tu l'utilises dans un nouveau projet, tu t'apercevra que les propriétés que tu vas entrer en mode création sont perdues dès que tu lances l'application. Regarde les évenements InitProperties, ReadProperties, WriteProperties, ainsi que l'aide sur les user control de msdn.
Bref, tu as dû bien t'amuser à faire fonctionner tout ça, et il t'en reste encore pas mal à faire ...
(fin du roman)
cs_Jack
Messages postés14006Date d'inscriptionsamedi 29 décembre 2001StatutModérateurDernière intervention28 août 201579 24 oct. 2003 à 12:03
Salut Gab
"plus stable" ? je ne connais pas de problème de stabilité aux WinSockets ...
Pour ce qui est des paquets qui s'entassent les uns derrière les autres, si tu sépares les envois avec un timer, tu perds en efficacité.
J'ai personnellement résolu le problème en faisant mon propre protocole d'échanges : Quand j'envoie des données, elles sont ibligatoirement encadrées par :
MotClé & Données & SéparateurMessage
où, par exemple, MotClé "Message" & Chr(0) et SéparateurMessage Chr(1)
A la réception, il n'y a plus qu'à tronçonner la chaine reçue :
- par paquets séparés par des Chr(1) pour séparer chaque message
- puis à l'intérieur de chaque message, par paquets séparés par des Chr(0) pour séparer le MotClé des Données.
Je vais quand même jeter un oeil à la source, les critiques étant toujours faciles ...
à plus ...
Jacck
22 août 2004 à 22:17
24 oct. 2003 à 20:12
24 oct. 2003 à 17:33
24 oct. 2003 à 13:38
- Déjà, on ne perd pas de temps à lire les commentaires ... il n'y en a pas : pas facile de découvrir à quoi peut bien servir telle ou telle fonction, ou même à savoir ce que viens faire la collection dans le projet, ou encore ce que viennent faire les modules d'encodage64 ...
- Et ... ça bug : Pour le TCP, si tu fais un "Envoyer" sans avoir précédemment le serveur en éEcoute", le texte n'est pas envoyé, ça c'est normal, mais, même si tu passes le serveur en "Ecoute", il ne reçoit pas les textes suivants !
- Tu parlais de stabilité des winsocket : Tu utilises l'OCX Winsocks dans ton controle ! Alors, quel intérêt ?
- Etant donné que tu as simplifié les commandes (je crois que s'est le but de ton appli, en fait), le composant Serveur ne peut communiquer qu'avec un seul client puisque tu fais un "Accept RequestID" sur le serveur en écoute. --> Faudra revoir la structure même du contrôle si tu veux pouvoir l'utiliser en multiclients.
La prochaine fois que tu fais un user control et que tu veux pouvoir le tester dans une appli, je te conseille ceci :
- Crée un projet pour ton controle utilisateur, et un second projet dans lequel tu voudras insérer le controle.
- Regroupe ces deux projets au sein d'un groupe de projet
Avec ça, tu t'apercevra vite que quelques anomalies notamment, celle là :
Si tu compiles ton user control, et que tu l'utilises dans un nouveau projet, tu t'apercevra que les propriétés que tu vas entrer en mode création sont perdues dès que tu lances l'application. Regarde les évenements InitProperties, ReadProperties, WriteProperties, ainsi que l'aide sur les user control de msdn.
Bref, tu as dû bien t'amuser à faire fonctionner tout ça, et il t'en reste encore pas mal à faire ...
(fin du roman)
24 oct. 2003 à 12:03
"plus stable" ? je ne connais pas de problème de stabilité aux WinSockets ...
Pour ce qui est des paquets qui s'entassent les uns derrière les autres, si tu sépares les envois avec un timer, tu perds en efficacité.
J'ai personnellement résolu le problème en faisant mon propre protocole d'échanges : Quand j'envoie des données, elles sont ibligatoirement encadrées par :
MotClé & Données & SéparateurMessage
où, par exemple, MotClé "Message" & Chr(0) et SéparateurMessage Chr(1)
A la réception, il n'y a plus qu'à tronçonner la chaine reçue :
- par paquets séparés par des Chr(1) pour séparer chaque message
- puis à l'intérieur de chaque message, par paquets séparés par des Chr(0) pour séparer le MotClé des Données.
Je vais quand même jeter un oeil à la source, les critiques étant toujours faciles ...
à plus ...
Jacck