2009-06-04 8 views
0

J'essaie de trouver un moyen simple de gérer la fiabilité des messages UDP. Je me suis dit que j'allais simplement envoyer chacun avec un ID de séquençage et en comparant l'ID à celui précédemment reçu, une perte peut être détectée. Normalement, j'utiliserais simplement des nombres entiers, mais l'idée que cela continuerait à augmenter indéfiniment ne me conviendrait pas.ID de séquence pour la gestion de la fiabilité

Je pourrais utiliser base64, mais cela ne ferait que le rendre un peu plus lisible mais ne résoudrait vraiment rien.

J'ai également considéré préfixer un timbre de date mais ce serait une sorte de bâclée lors de la distribution des messages reçus vers minuit. Je pense qu'il doit y avoir une meilleure solution que quelqu'un pourrait suggérer, même si cela consiste simplement à coller avec des nombres entiers.

Répondre

1

Ma préférence pour ce travail particulier consiste à utiliser une séquence entière incrémentée (au moins 64 bits) ensemencée avec un horodatage haute résolution. De cette façon, même s'il y a une perte d'état à la fin de l'envoi, quand la séquence est ré-ensemencée à partir du moment, il est fort probable que l'on saute simplement en avant. Tous les bogues de l'année 10K que cela pourrait introduire sont laissés comme un exercice pour Lazarus Long. :-)

Gardez à l'esprit que la détection de l'écart de séquence est essentiellement une optimisation. L'extrémité émettrice doit retransmettre jusqu'à ce qu'un accusé de réception soit reçu, avec un «nack» (pour un intervalle ou un datagramme corrompu) provoquant simplement une retransmission plus tôt. (ZMODEM est une rare exception à cette règle, son mode de fonctionnement par défaut étant l'utilisation d'un seul accusé de réception à la fin du flux et de toutes les autres retransmissions régies par des nacks, mais comme un protocole de transfert de fichiers datagramme en plusieurs parties.)

0

Utilisez TCP? Je ne veux pas être sarcastique, mais c'est pourquoi TCP est là.

Questions connexes