Discussion :

[dagos]

Bonjour,

Je développe actuellement une application client / serveur qui communique par UDP.
Mes 2 machines sont sur un réseau local d'entreprise (il y a pas mal de machines sur le réseau local).
Le flux de données entre le client et le serveur est assez faible:
Maximum 60 paquets par seconde de 600 octets maximum (soit 300 Kb/s grand maximum).

Je voudrais savoir s'il existe un moyen de savoir si un paquet UDP s'est perdu.
Par exemple, si le port coté client n'est pas ouvert, un paquet ICMP indique 'port unreachable' (et dans ce cas le paquet ne s'est pas perdu).
Y a t-il un paquet ICMP dans le cas d'une perte de paquet ?

L'absence de paquet ICMP, et la non réception d'une donnée indique t'il que le paquet a été perdu ?
(je suis sur d’être dans le 'recvfrom' lorsque le paquet est envoyé mais je ne le reçois pas).

En UDP, la pile IP UNIX mémorise t-elle bien les paquets une fois le 'bind' réalisé, pour les restituer lors du 'recvfrom' (comme en TCP) ?

Etant donné le faible flux de données, est-ce normal qu'il y ait des pertes de paquets ?

Merci pour vos réponses

[Invité]

Salut,

voilà très longtemps que je n'ai pas mis la main dans ce genre de cambouis...

Je voudrais savoir s'il existe un moyen de savoir si un paquet UDP s'est perdu.
Par exemple, si le port coté client n'est pas ouvert, un paquet ICMP indique 'port unreachable' (et dans ce cas le paquet ne s'est pas perdu).
Y a t-il un paquet ICMP dans le cas d'une perte de paquet ?

Non, le stack n'émettra aucun ICMP pour un datagramme UDP perdu, c'est aux couches hautes de gérer cet incident.

L'absence de paquet ICMP, et la non réception d'une donnée indique t'il que le paquet a été perdu ?
(je suis sur d’être dans le 'recvfrom' lorsque le paquet est envoyé mais je ne le reçois pas).

Ton problème donne plutôt l'impression que certains paquets sont "silently dropped" et c'est souvent lié aux RX buffers dont il faut augmenter la taille. Après, tout dépend où tu envoies le flux UDP. C'est quoi comme application ?

Steph

[dagos]

Salut,
merci pour ta réponse.
C'est du TFTP.
En gros pour télécharger un fichier, il est découpé en blocks (< 1ko dans mon cas) qui sont numérorés, envoyés et acquités les uns après les autres.
Du coup il n'y a jamais plus d'un block dans le buffer RX.
Je vais quand même essayer de l'augmenter au cas où...

Je me disais aussi que ça pouvais être lié au fait que je me connecte en 'ssh' à la machine qui reçoit les blocks de données, et que du coup c'était peut-être ça qui congestionnait un peu trop le réseau.
Je ferrais quelques essais aussi là dessus.

J'essayerai aussi en me connectant en direct (sans passer par le réseau) et en utilisant une interface éthernet dédiée, pour voir si j'ai toujours des pertes.
++

[Invité]

OK. Mais ne t'attends pas à avoir des performances phénoménales avec TFTP. Ce protocole "lock-step" est terriblement limité au RTT entre les 2 machines et je ne pense que l'augmentation des buffers améliore les choses puisque le client devra de toutes façons attendre l'ACK pour envoyer le prochain block.

Pour revenir à tes performances, sachant que tu es à 60 blocks TFTP par seconde, ça signifie que le RTT entre les 2 machines devrait être de l'ordre de 15 ms. Si ça n'est pas le cas, effectivement ça n'est pas normal.

Une autre direction à explorer concerne le Transfer Size Otion (RFC2347) pour augmenter les blocks au-dessus de 1K.

Steph

[gangsoleil]

Bonjour,

Pourquoi utiliser tftp et pas sftp ?

Sinon, pour repondre a tes questions sur UDP, il n'y a aucun controle a aucun niveau : c'est au developpeur de l'application de prendre ca en compte et d'implementer un mecanisme si besoin.

Dans le cas que tu cites, numeroter les paquets avant de les envoyer, puis les acquiter un a un, c'est a peu pres le pire mecanisme que l'on peut imaginer, mais c'en est un. Mais dans ce cas, l'utilisation de TCP serait plus judicieux (possibilite d'acquiter plusieurs paquets en une seule fois notamment).

[dagos]

Salut,

J'utilise TFTP parceque je n'ai pas le choix... Je m'interface à une application déjà existante.
Ce n'est pas les perfos qui m’intéressent mais bien la perte des paquets...
Je pense que j'ai bien des pertes de paquets, sinon j'aurais des ICMP m'indiquant que le paquet n'a pas été transmis à la couche applicative.

Je vais me pencher sur la gestion de la perte de ces paquets du coup...
merci à vous, je clos le sujet

[Invité]

Je pense que j'ai bien des pertes de paquets, sinon j'aurais des ICMP m'indiquant que le paquet n'a pas été transmis à la couche applicative.

Quel type d'ICMP pourrait envoyer un tel message au client ?

Steph

[dagos]

ICMP Port Unreachable est généré si je ne suis pas en écoute sur le port concerné.
Donc si le paquet n'est pas 'dropé' par les couches basses ni reçu par la couche applicative, c'est qu'il a été perdu.
++

[Invité]

Il se peut aussi que l'appli soit bien en écoute sur le port concerné mais qu'il lui soit impossible de le traiter en raison d'un manque de ressources/buffers. Auquel cas le stack devrait émettre un ICMP Source Quench.

Mais de nos jours, l'implémentation du Source Quench est de plus en plus rare. Ce qui conduit à une situation de paquet "silently dropped".

Je suis intéressé sur la suite de ton problème, j'espère que tu nous tiendras postés.

Steph

[gangsoleil]

ICMP Port Unreachable est généré si je ne suis pas en écoute sur le port concerné.

Es-tu certain que cet ICMP est genere par la machine, et que le trafic ICMP est bien route jusqu'a l'emetteur ? Est-ce que tu as fait le test ?

Une bonne solution de diagnostic est de monitorer le trafic sur l'emetteur et sur le recepteur (pour les tests uniquement), par exemple avec tcpdump ou wireshark : tu pourras voir ce qui se passe reellement (perte de paquet, paquets arrivant dans le desordre, ...)

[dagos]

Salut,
ICMP est bien géré des 2 cotés.
J'ai fais la manip avec WireShark des 2 cotés, et effectivement, je vois bien que certains paquets n'arrivent jamais (j'aurais du y penser plus tôt d'ailleurs...).

Sinon j'ai pensé à faire un raw socket sur la machine qui exécute l'application que je ne peux pas modifier pour intercepter les paquets UDP, et les envoyer en TCP à mon client (que je peux modifier) pour être sûr de ne pas perdre de données... mais c'est pas vraiment simple... mais ça doit être faisable (et ça sort du sujet...).

Si jamais je me lance là dessus je vous tiens au courant...