Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Le problème, c'est que le thread #1 ne sait pas si le client vient du thread #2 ou d'un autre processus tant que recv() n'a pas retourné.
Donc, le thread #1 doit obligatoirement faire le recv().
Résultat, si un client extérieur se connecte puis n'envoit rien du tout, le serveur reste bloqué sur le recv() en attendant que le client envoie.
Résultat, si je fais un client qui se connecte puis plus rien, j'ai lancé une attaque Denial of Service sur le serveur de Gruik à peu de frais...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Et alors? Ce problème existe de toute façon, même en dehors de la question d'arrêter proprement le thread#1.Envoyé par Médinoc
Ben non : Si le thread 1 ne fait pas lui-même le recv(), ou s'il utilise select(), il ne sera pas bloqué par un seul client.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
On peut considérer que les "clients" ne seront jamais autre chose que des applications internes, et yaurait pas lieu d'etablir une vraie robustesse à ce niveau là
Je ne saisis pas. Il faut bien que quelqu'un le fasse ce recv()?!?! En outre, select() permet juste de savoir si accept() retournera, non? Cela ne garantit pas que recv() retournera aussi.
perdu, ça teste pour les deux si on lui passe les deux sockets (ou beaucoup plus)
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Désolé mais je ne comprends toujours pas votre explication. Vous utilisez select() sur 2 sockets: la #1 qui sert à la communication avec les clients et la #2 qui permet d'envoyer des messages de contrôle. Si lors d'un select(), seule la socket #1 est identifiée dans le paramètre readfs de select(), alors vous allez faire un accept() puis un recv(), et donc vous êtes confronté au même problème, à savoir que le client peut ne pas envoyer de données.
Ben non : Si la #1 est "identifiée dans le paramètre readfs de select()", alors on fait juste le accept() et on l'ajoute aux prochains select()...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
D'accord, et donc au prochain select(), si la socket #1 est identifiée dans readfs, alors cela signifie que recv() ne bloquera pas, c'est bien cela?
Pas la socket #1 : La socket retournée par accept().
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Oui, c'est juste. OK, merci pour l'explication. J'ai saisi maintenant.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager