Assurer la réception d'un message UDP

[Davidlouiz]

Bonjour,

Dans le cadre du développement d'une application temps réel, j'ai besoin d'envoyer des messages à un serveur. Ces messages doivent parvenir au serveur le plus rapidement possible. L'ordre d'arrivé des messages n'a pas d'importance. Je pensais donc à utiliser UDP.

Mon problème, c'est qu'il s'agit de messages qui ne "doivent" pas être perdu. J'aimerai ne pas en perdre plus d'un sur 10 000 messages.

Je pensais donc à envoyer ces messages en 5 exemplaires à chaque fois. Le premier message valide qui arrive est décacheté. Mais j'ai peur qu'en cas de perte due à une congestion, cela ne fasse qu'empirer les choses.

Une autre solution consiste à créer une collection de message à envoyer. Lorsque je dois envoyer un message, je l'ajoute à la collection. Et une tâche se charge d'envoyer le courrier en boucle, de façon répétée et ne retire le message qu'après avoir reçu un accusé de réception.

Je voulais savoir s'il existe des mécanismes de ce genre permettant d'assurer la réception de message rapide/simple/efficace.

Merci.

[-ed-]

Si le message est court, TCP est à la fois fiable et performant.

Sinon, UDP est très fiable mais l'ordre n'est pas garanti et un message peut être perdu. On peut implémenter un mécanisme de numérotation dans le message avec un checksum pour être sûr qu'il soit valide et le redemander en cas de problème. On peut aussi acquitter les messages reçus pour désengorger l'émetteur au fur et à mesure (car pour pouvoir renvoyer les messages, il doit les conserver en mémoire).

Conception d'un protocole à l'arrache :

Émetteur :

Émettre un message :

-Allouer un message
-Lui donner un nouveau numéro unique (absent du tableau d'indexation courant). La recherche se fait à partir du premier 'non libre'. On peut maintenir sa position dans une variable... Nota : par définition, l'adresse est un numéro unique ... Ca peut simplifier le mécanisme ...
-Calculer le checksum du message
-Placer le checksum dans le message
-Placer le numéro et l'adresse dans un tableau et le trier par numéro (indexation)
-Émettre le message, noter l'échéance (date + 2 ou 3 secondes max, selon granularité de la date) dans le tableau d'indexation. On peut aussi prévoir une purge automatique selon une date de fin de vie à date initiale + 20 ou 30 s, par exemple, avec log des messages non acquittés, pour statistiques de performance etc.

Dans la tâche de réception :

-Attendre l'acquittement (avec numéro du message)
-Si il est OK, retirer le message de la liste, remplacer le numéro par 0 ou -1, quelque chose qui veut dire 'libre'. Libérer le bloc, Trier le tableau d'index.
-Sil il est KO ou si le délai imparti est écoulé (si la date courante est >= à l'échéance, réémettre le message (noter la nouvelle échéance)

La surveillance de la date et l'évaluation des échéances se fait à chaque nouvel évènement de réception et par polling régulier (select() est idéal pour ça)

Nota. Comme l'adresse, la date peut être 'unique' si la granularité est suffisante ...

Récepteur :

Vérifier le checksum

OK -> renvoyer OK avec le numéro de message
KO -> renvoyer KO avec le numéro de message (en espérant que ce n'est pas lui qui est KO. Dans ce cas, on ne renvoie rien et le timer fera le travail.

Nota : une redondance triple est possible, par exemple le numéro est mis 3 fois dans le message émis. En cas de doute, on prend les 2 qui sont identiques. Si les trois sont différents, on ne renvoie rien et on attend que le timer tombe coté émission.

Avant de réinventer la roue (on est en gros en train de réécrire TCP ...) le mieux est de faire des essais en TCP pour mesurer les temps de réponse.

[Davidlouiz]

UDP est très fiable

Qu'entends-tu par fiable ?

Est-ce qu'un message transporté par UDP peut être modifié en cours de route ?

[-ed-]

Si une trame UDP est reçue, sont contenu est correct. Si le contenu est erroné, la trame est rejetée et donc non reçue (du point de vue applicatif). C'est donc au protocole applicatif de gérer la continuité du message.