Discussion :

[Guismo1979]

bonjour,

j'ai un probleme avec l'envoi de paquets IP/UDP d'un client vers un serveur. le serveur renvoyant au dernier client qui lui a envoyé un paquet , le nomde de paquets recus !

mes tests on été :

envoi de 1024 paquets de 128 'a' => j'en recois 188 346 744 1024 +/_ mais j'aimerais 1024 tout le temps !!

j'ai essayé 1024 paquets de 1280 bytes => j'ai tout recu ! (plusieurs fois)
j'ai essayé 60 000 paquets de 1280 bytes => j'ai recu +/- 59 000 paquets
j'ai essayé 600 000 paquets de 4800 bytes => j'ai recu +/- 590 000 paquets

ensuite j'ai optimisé mon code pour envoyer plus rapidement !!

j'ai essayé 600 000 paquets de 4800 bytes => j'ai recu +/- 39 000 paquets

ma conclusion c'est qu'il y a du drop quelque part !! mais je ne sais pas ou et j'aimerais le savoir !! ;-)

ma question est : combien au max je peux envoyer de paquets !! a la minute, a la seconde ... et de quelle taille doivent il etre ?


autre question : comment faire pour ecouter sur un socket pendant un temps donné par ex 5 sec max et pas indefiniment!!
=> parce que j'utilie la fonction alarm(XX) mais je ne sais pas comment cela se fait , j'ai un integer (sans doute autre chose ailleurs ) qui est modifié ( le nombre de paquets recus justement ) qui passe de 188 a -1578954654354 (ou qqch du genre)


merci de votre patience
@+

Guismo / OutMaX!

[vic]

C'est la nature même de l'UDP que d'être un protocole non fiable, il est utilisé précisément lorsque les données à transmettre sont non critiques et dans des conditions qui rendraient une connexion TCP peu performante.

Il est impossible de dire avec certitude si un paquet udp va arriver ou non, même aux plus bas débits (nature "connectionless" de l'udp : une fois envoyé le paquet est livré à lui-même).

Le code de gestion des paquets perdus ne fait pas partie du protocole contrairement au tcp, tu devras donc t'en charger toi même.

Pour écouter sur des socket avec timeout -> select(). Regarde la doc le fonctionnement en détail serait bien trop long à expliquer ici.

vic

[Guismo1979]

merci !

mais pour ce qui est d'udp , il faut pas exagerer sur les pertes !!

le drop des paquets ne se fait que s'il y a congestion non ?

donc j'aimerais savoir quelle est la limite de congestion :-)

[Guismo1979]

l'on m'a dit d'utilliser la fonction select() pour realiser une attente sur le socket...

et d'attendre entre l'envoi de deux paquets de telle sorte qu'il y aie moins / pas de drop ...

mon probleme est que je ne voit pas comment obtenir l'entier qui défini le File Descriptor du socket correspondant ...

merci pour l'aide que vous pourriez m'apporter

Guismo / OutMaX!

[Guismo1979]

C'est la nature même de l'UDP que d'être un protocole non fiable, il est utilisé précisément lorsque les données à transmettre sont non critiques et dans des conditions qui rendraient une connexion TCP peu performante.

Il est impossible de dire avec certitude si un paquet udp va arriver ou non, même aux plus bas débits (nature "connectionless" de l'udp : une fois envoyé le paquet est livré à lui-même).

Le code de gestion des paquets perdus ne fait pas partie du protocole contrairement au tcp, tu devras donc t'en charger toi même.

Pour écouter sur des socket avec timeout -> select(). Regarde la doc le fonctionnement en détail serait bien trop long à expliquer ici.

vic

de nouveau...

je pensais mes problemes envolés mais non!!! ils sont revenus !! ou jamais partis c'est selon !!

mon probleme est le suivant.

je fais un select... ==> j'obtient une reponse comme quoi il y a un paquet a lire...

je fais alors un recvfrom ..... et la ... il bloque !!!!! pq ? parce qu'il n'y a rien a lire...

explication ?????

et celui qui me dira qu'en UDP , les paquets ne sont pas sur d'arriver... je l'egorge ... pcq c'est comme si on disait ... que ton amis qui a traversé les mers en canoé pour venir te voir sonnait au pas de ta porte... et comme par hasard, une fois qu'il a sonné , il disparait... (desolé pour l'analogie ... mais c'est tout a fait ca... )

[vic]

Un détail : le drop se fait aussi bien s'il y a congestion ou pas, c'est juste un peu plus fréquent si le réseau est congestionné.

Pour ton dernier post : le select() retourne bien car il y a un paquet dispo ou à cause du timeout ? (valeur de retour de select)

En tout état de cause, un 'man select_tut' ne peut pas faire de mal.

vic

[Guismo1979]

le drop en UDP se fait a cause de :

1) congestion
===> sur la ligne utilisée, les routeurs droppent...

2) rapidité du flux
====> j'emet a 100 Mb et je recois a 10Mb => je recois 1/10 ...

3) problemes sur les lignes...

il n'y a aucun mecanisme pour faire du drop , on est en best effort et le paquet tente par tous les moyens d'arriver a destination ...


et pour mon super select() , j'ai bien une valeur de retour qui me dit qu'il y a qqch a lire...
et j'espere pour l'implementation UDP qu'elle ne drop pas dans son buffer ... mais en queue de buffer quand celui ci est plein ... donc je ne comprends toujours pas pourquoi, quand je recois un retour qui me dit qu'il y a un paquet, une fois que je fais le recvfrom() il me plante mon programme alors qu'il devrait lire....

ps: derniere et ultime solution ,

FD_ZERO(&rfds_client);
FD_SET(sock, &rfds_client);

ceci ne suffit peut etre pas pour n'avoir que le socket "sock" sur mon descripteur de fichier

A L'AIDE... il me reste plus qu'un mois pour tout finaliser et la je suis bloqué pour une betise

merci