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.

[ram-0000]

Pour moi, XP 32 bits

unsigned long long int = 64 bits (pareil pour signed long long int)
unsigned long int = 32 bits (pareil pour signed long int)
unsigned short int = 16 bits (pareil pour signed short int)

[3DArchi]

Bonjour,
Comme indiqué précédemment, UDP ne garantie pas le séquencement des trames. Pour le problème de ta numérotation, en général, cela se règle par fenêtre : Si ID_Max-Fenetre<ID_Recu<ID_Max, alors ID_Max reste inchangé, sinon ID_Max = ID_Recu. La taille de la fenêtre est liée à la fréquence des envois et le temps d'acheminement.
Sur ton problème de taille, le standard n'impose
(1)qu'une relation d'ordre entre les types : sizeof(char)=1<=sizeof(short int)<=sizeof(int)<=sizeof(long int)<=sizeof(long long int)
(2) des plages minimums pour les types

#define SCHAR_MAX +127
#define SCHAR_MIN -127
#define SHRT_MAX +32767
#define SHRT_MIN -32767
#define INT_MAX +32767
#define INT_MIN -32767
#define LONG_MAX +2147483647
#define LONG_MIN -2147483647
#define LLONG_MAX +9223372036854775807
#define LLONG_MIN -9223372036854775807

A comprendre : int doit pouvoir représenter entre -32767 et +32767. Mais peut très bien représenter entre -2147483647 et +2147483647 car [-32767;+32767] appartient à [-2147483647;+2147483647]
Donc tu peux très bien avoir sizeof(int)=sizeof(long) ou pas...

Ensuite :
-> short == short int
-> long == long int
-> long long == long long int
Donc si on reprend ton exemple :

Code :

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

1
2
3
4
 
sizeof(int) = sizeof(unsigned int) // (1)
sizeof(unsigned long int) = sizeof(unsigned long) // (2)
sizeof(unsigned long long) = sizeof(unsigned long long int) // (3)

La seule garantie que tu as est : (1)<=(2)<=(3).
Mais tu peux avoir (1)=(2)<(3)
ou (1)<(2)=(3)

[f-k-z]

D'accord, merci bien pour toutes ces infos!

[koala01]

Salut,

Une solution pourrait être de travailler, pour ton compteur, en "binaire réfléchi" (on parle aussi de "gray binaire", plutôt qu'en binaire converti décimal, comme à l'habitude...

L'idée est de faire en sorte qu'entre deux paquets qui se suivent dans la séquence d'envoi, il n'y ait jamais qu'un seul bit de différence au niveau de la valeur de récupération...
Voici un tableau comparatif des valeurs de 0 à 7 pour expliquer le principe:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
BCD    decimal  gray binaire
0000  ==> 0  ==>  0000 
0001  ==> 1  ==>  0001 
0010  ==> 2  ==>  0011
0011  ==> 3  ==>  0010 
0100  ==> 4  ==>  0110 
0101  ==> 5  ==>  0111
0110  ==> 6  ==>  0101
0111  ==> 7  ==>  0100
...

Cela demande bien sur un peu de "gymnastique mentale" pour arriver à créer les valeur (et encore, la logique est finalement simple ) mais la vérification de l'ordre dans lequel les paquets sont reçus s'en trouve simplifiée

[f-k-z]

Merci pour l'info, je ne connaissais pas cette technique

[koala01]

Au passage, voici un lien qui le présente correctement

[Médinoc]

Pour le coup des tailles, ça dépend de l'OS:

• La plupart des systèmes unixoïdes 64 bits utilisent le modèle LP64 (Long and Pointer 64 bits), donc les long int font 64 bits, la même taille que les long long int.
• Win64 utilise le modèle LLP64 (Long Long and Pointer 64 bits), donc les long int restent à 32 bits, et seuls les long long int font 64.
  Ces tailles sont inchangées entre Win32 et Win64: Seuls changent les pointeurs (et handles Windows) et les types du genre size_t/intptr_t.