Discussion :

[damdam78]

Bonjour,

Je travail actuellement sur une application qui utilisent des sockets non bloquantes pour l'envoie de paquets en UDP.
L'application reçoit des donné d'un pc du réseau, les traite et les renvoie en UDP (broadcast) pour d'autres ordinateurs.
Le problème vient du fait que des paquets sont transmis en permanence, mais de temps en temps certains paquets ne sont pas émis (avec l'erreur WSAWOULDBLOCK, avec quelques minutes entres chaque erreur).
J'ai essayé d'augmenter la taille des buffer d'émission et de réception mais rien n'y fait. L'erreur se produit même sur des paquets de petites taille.

Auriez-vous une idée permettant de résoudre le problème que je rencontre ?

Je vous remercie par avance

[3DArchi]

Effectivement, WSAWOULDBLOCK indique que ton buffer d'émission est plein. Même avec des petits paquets si tu émets par rafales, cela peut se produire. Quelles solutions? Puisque t'es sur UDP, je dirais que normalement ton protocol applicatif devrait se permettre de se passer de ces packets! Sinon, tu peux toujours gérer ta propre chaîne de buffer d'émission par derrière, mais tu risques de rencontrer le problème un peu plus tard (quand tu ne pourras plus allouer)!

[wiztricks]

Avec des sockets non bloquantes, vous pouvez tout à fait demander à transmettre plus de paquets que la pile IP ne sera capable de pousser sur l'interface réseau.

Avant d'essayer de trouver des solutions, il serait peut être sage de considérer quelque peu la bande passante réseau utilisée par votre application

• est-ce raisonnable? dans quelles conditions çà déborde?
• y a-t-il des alternatives? quelles implications?

Si vous voulez que les paquets soient transmis au moins une fois, il faudra attendre que la pile IP les accepte. Cela pourra ralentir la lecture des requêtes et réguler le flux de bout en bout.

Note: Bien que vous travailliez en UDP, je suppose que les messages émis sont attendus par les clients. Que se passe-t-il s'ils ne les recoivent pas? Ils re-soumettent le boulot déjà fait?
Dans ce cas, vous comprendrez que "jeter" des paquets signifie refaire du boulot et donc gaspiller une bande passante qui vous fait déjà défaut.
-W

[damdam78]

Merci pour vos réponses.

En effet l'application qui reçoit les messages permet de mettre à jour une carte (géographique) avec des éléments dessus. Tant qu'un nouveau message n'est pas reçu, l'affichage n'est pas remis à jour et attend un message pour se rafraichir.
Ce que j'ai remarqué, c'est lors de ces erreurs WSAWOULDBLOCK, certaines dérèglent mon affichage (suppression d'information, décalage...) et se remettent correctement lors de la réception d'un nouveau paquet. Il me semble donc vu cette constatation, que mon message est émis de manière incorrecte (le message n'est pas complet, il est corrompu...).
C'est ce problème de saut des informations de ma carte que j'essaie de supprimer, je souhaite donc résoudre ce problème à la source: en éliminant les erreurs d''emission WSAWOULDBLOCK.

Pour information j'utilise la fonction sendto des winsock2.

Merci pour votre aide!

[3DArchi]

Pour reformuler ce que j'avais dit, à partir du moment où les échanges se font en UDP, cela veut dire qu'il faut savoir gérer la perte de paquets. Donc à mon avis, toute tentative d'intervenir sur les réseau ne fait que décaler un pb potentiel. Il serait plus pertinent de travailler sur l'affichage avec des données moins à jour ou pas tout à fait cohérentes mais que cela reste transparent pour l'utilisateur.

[Emmanuel Delahaye]

Je travail actuellement sur une application qui utilisent des sockets non bloquantes

Pourquoi non bloquante ? C'est une source d'ennuis bien connue, la preuve.

Utilise les sockets bloquantes (synchrones) et tu n'auras pas de problèmes de congestion. Si les attentes sont gênantes, utilise un thread par fonction bloquante.

[damdam78]

Je te remercie pour ta réponse, mais en fait nous avons crée un dll qui réalise tout le protocole de connexion et d'envoi/réception des messages pour que ce soit transparents pour les applications qui les utilise.
Donc pour le moment ce n'est pas possible de modifier le fonctionnement de cette dll.

Je me demandai s'il est possible de vérifier l'état du buffer du socket avant d'appeler la fonction sendto pour être sûr qu'elle réussisse ?

Merci

[Emmanuel Delahaye]

Je te remercie pour ta réponse, mais en fait nous avons crée un dll qui réalise tout le protocole de connexion et d'envoi/réception des messages pour que ce soit transparents pour les applications qui les utilise.
Donc pour le moment ce n'est pas possible de modifier le fonctionnement de cette dll.

Visiblement, cette DLL est buggée. Il faut la corriger ou en écrire une autre. C'est pas en bricolant à droite à gauche qu'on arrive à quelque chose...

[damdam78]

Visiblement, cette DLL est buggée. Il faut la corriger ou en écrire une autre. C'est pas en bricolant à droite à gauche qu'on arrive à quelque chose...

C'est bien ce que j'essaie de faire en supprimant les bugs de cette dll.
Je viens d'essayer la fonction "select". Elle a l'air de fonctionner correctement.
Par contre cette fonction rend bloquant mon programme.
Existe-il une fonction du même type que select qui renvoie un code d'erreur disant que le buffer socket en émission est plein et donc qu'une émission n'est pas possible sans rendre mon programme bloquant ?

Merci

[Emmanuel Delahaye]

C'est bien ce que j'essaie de faire en supprimant les bugs de cette dll.
Je viens d'essayer la fonction "select". Elle a l'air de fonctionner correctement.
Par contre cette fonction rend bloquant mon programme.
Existe-il une fonction du même type que select qui renvoie un code d'erreur disant que le buffer socket en émission est plein et donc qu'une émission n'est pas possible sans rendre mon programme bloquant ?

Il faut vraiment cesser le bricolage.

Soit tu choisis la facilité (mode synchrone : fonctions bloquantes + threads) et ça marche tant qu'il n'y a pas des milliers de clients à traiter en même temps, soit tu choisis la voie royale (asynchrone : fonctions non bloquantes 'send and forget' et tu apprends à gérer l'asynchronisme correctement, notamment en traitant les évènements de fin d'émission, ce qui permet d'éviter d'émettre trop vite... select() peut aider mais est forcément bloquante (il faut bien attendre les évènements quelque part...).

C'est un métier...

Maintenant, si tu me dis que c'est l'application qui a été conçue pour utiliser de travers le mode asynchrone, c'est l'application qu'il faut réécrire... (ou alors c'est à la DLL de sérialiser les demandes avec une liste chainée et de faire des émission synchrones...simple, ou asynchrones... compliqué)

[nicroman]

Existe-il une fonction du même type que select qui renvoie un code d'erreur disant que le buffer socket en émission est plein et donc qu'une émission n'est pas possible sans rendre mon programme bloquant ?

Oui... send... qui renvoit WSAEWOULDBLOCK si c'est plein !

Sinon, tu peux attacher un signal au 'write' qui te diras si le buffer est plein ou non, mais dans ce cas, difficile de savoir quelle quantité de buffer est disponible.
La gestion de paquets en local est à mon avis superflu, tu risque d'entrer dans des problêmes de gestion de mémoire bien plus "graves" à mon avis.
Quant à passer aux sockets bloquants, c'est une solution de facilité....