Discussion :

[f-k-z]

Bonsoir à tous,

Travaillant en ce momment sur un programme d'envoi de donnée à la chaine en UDP depuis un programme serveur, j'aurais besoin de ne réccuper que la trame UDP la plus récente afin de pouvoir l'exploiter à sa réception sur le client.

Par exemple depuis le serveur j'envoi les donnée suivante:

Donnée 1
Donnée 2
Donnée 3
Donnée 4
Donnée 4

Puis sur le client je recois les données dans cet ordre:

Donnée 1
Donnée 3
Donnée 4
Donnée 2
Donnée 5

Comment faire pour ne pas traiter la donnée 2 vu que j'ai déja reçu la donnée 3 en sachant que je ne connais pas le contenu des données 1 à 5 ?

Cordialement,

F-k-z

[ram-0000]

Déjà, en UDP, il n'y a pas d'info qui pourraient t'aider. Le protocole UDP est un protocole sans garantie d'acheminement ni de séquencement.

C'est donc au niveau applicatif que cela doit se gérer.

Côté emetteur, je verrai bien un truc qui donne un numéro de séquence dans les données applicatives qui s'incrémente à chaque paquet émis.

Coté récepteur, tu ne traites le paquet que si le numéro de séquence est strictement supérieur au dernier traité.

Et un petit cas particulier, si le récepteur recoit un paquet dont le numéro de séquence est 0, il doit resetter le dernier numéro de séquence recu et traiter ce paquet. Cela permet qu'en cas de relancement de l'émetteur et de reprise à 0 des numéro de séquence, le (ou les) récepteur puisse se resynchroniser.

[f-k-z]

Je comptais utiliser un entier non signé long, mais comme j'envoie en continue sur une longuer période n'y a t'il pas de risque je dépasse la limite ?

Ou si sur le serveur j'arrive à FF FF FF FF FF FF FF FF (capacité maximale de mon unsigned long int, si je ne me trompe pas), je retourne à 0.
Et avec ta méthode, de faire mon reset, je retombe sur mes pattes, mais s'il y a perte du paquet, chose possible vu que je suis en UDP, il faudrait que je mette une condition du genre,

Si (paquetprécédant - paquetactuel > 100) {
Alors je traite le paquetactuel
Sinon je continue
}

Cela parait correct ?

[ram-0000]

un entier non signé long, c'est 4 octets donc un nombre de 4 milliard (FF FF FF FF et non pas FF FF FF FF FF FF FF FF comme tu l'as écrit).

A raison d'un paquet par seconde, cela fait 136 ans. Après, à toi de voir si tu risques de faire "tourner" ton compteur.

Sinon, après, il y a les unsigned long long qui sont sur 64 bits et ce type est maintenant supporté sur beaucoup de plateformes.

[f-k-z]

C'est vrai qu'avec 4 octets cela devrait suffit, parcontre, question qui n'a rien à voir avec le reseau mais pour la taille des int long int etcetc.
Le programme suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
#include <stdio.h>
 
int main(){
        printf("ULInt %d\n", sizeof(int));
        printf("ULInt %d\n", sizeof(unsigned int));
        printf("ULInt %d\n", sizeof(unsigned long int));
        printf("ULInt %d\n", sizeof(unsigned long long));
        return 0;
}

Me retourne le résultat suivant:

ULInt 4
ULInt 4
ULInt 8
ULInt 8

donc un unsigned long int aurait la même taille qu'un unsigned long long ? (testé sur une plateforme 64bits). Est-ce la même chose sur tous les systèmes ou il y a une différence avec une version 32bits

[Goten]

Sur ma machine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
    std::cout << sizeof(unsigned long long) << " " << std::numeric_limits<unsigned long long>::max() << std::endl;
    std::cout << sizeof(unsigned long) << " " << std::numeric_limits<unsigned long>::max() << std::endl;
    std::cout << sizeof(unsigned int) << " " << std::numeric_limits<unsigned int>::max() <<std::endl;
    std::cout << sizeof(int) << " " << std::numeric_limits<int>::max() << std::endl;

Me sort l'output suivant :

8 18446744073709551615
4 4294967295
4 4294967295
4 2147483647

Avec mingw sous xp 32bits.