lire en C++ un socket ouvert par l'alignement de la structure Java +

Question

J'essaye d'écrire dans Linnux un client en C++ en utilisant boost::asio des données d'un socket. Le serveur est construit en Java. Le problème que j'ai maintenant, c'est que je ne peux pas lire correctement certaines informations de la socket. Si le client est fait en Java, tout va bien.

Dans les détails la grande erreur que j'ai sont dans la réception du unsigned long et du int dans la structure ci-dessous. Je prévois une valeur pour anInteger devrait être 0x00000005 donc 5, mais la lecture de la prise me donne 0x03000 (?!?!). C'est vraiment un nombre différent et basé sur l'impression hexadécimale j'ai moins de chiffres (?!?!?).

Pour aUnLong je devrais recevoir quelque chose d'approchant à un certain nombre 1279272977799 donc dans l'hexagone est 0x129DA9C8587, au lieu d'une recevoir quelque chose comme 0x00129ffffffdaffffff8fffffff9f5c. Je vois que certaines informations sont bonnes mais elles sont mélangées à tous les ff et je ne sais pas d'où elles viennent.

Je reçois à chaque fois 168 octets (nombre d'octets ainsi fixé). Au début, je pensais à l'alignement des données de ma structure, donc j'ai présenté attribute((packed)). Les numéros label et lbl_2 sont des chaînes; Je maintenant que JAVA utilise UTF mais il n'est pas clair pour moi comment cela joue dans ce scénario.

Pouvez-vous m'aider avec ce problème?

Je vous remercie beaucoup.

EO

 
union MyStruct 
{ 
    char buffer[168]; 

    struct _data{ 
     char   dash[2];  
     unsigned long aUnLong; 
     char   label[128]; 
     char   lbl_2[24]; 
     int   anInteger; 
    } __attribute__((__packed__)); 

    _data data; // the real data 
}; 

lecture se produit en utilisant cette simple ligne

 
MyStruct obj; 
size_t reply_length = asio::read(s,asio::buffer(obj.buffer, 168)); 

c'est le format original envoyé

 
byte 000,001: # 
byte 002-010: aLong (8 byte) long - milliseconds since 1-1-1970 in UTC 
byte 011-139: label (128 byte 2byte per character) label_1 
byte 140-164: lbl2 (24 byte 2byte per character) label2 code 
byte 165-169: anInteger (4 byte) integer 

Answer 1

Votre structure ne semble pas être 168 octets systèmes communs. Si long est de 4 octets (typique dans la compilation 32 bits) alors votre structure est probablement 162 ou 164 si le paquet n'est pas respecté. Si long est de 8 octets, alors 164 ou 168 (si rembourré, ce que vous supposez est mauvais).

Vérifiez le sizeof(_data) dans votre programme et voyez ce que le compilateur vous dit.

En outre, vos informations de format d'origine prêtent à confusion. Par exemple, vous dites "octet 002-010: long (8 octets) long", mais les octets 2-10 sont neuf (9) octets non 8. Y at-il un crc ou un octet de somme de contrôle?