用 C++ 阅读由 Java 打开的套接字结构对齐

发布于 2024-09-09 22:35:16 字数 1531 浏览 2 评论 0原文

我正在尝试使用来自套接字的 boost::asio 数据在 Linnux 中用 C++ 编写客户端。服务器是用Java构建的。我现在遇到的问题是我无法从套接字正确读取某些信息。如果客户端是用JAVA完成的一切都可以。

详细来说,我遇到的最大错误是接收下面结构中的 unsigned longint 。我期望 anInteger 的值应该是 0x00000005 所以 5,但是从套接​​字读取给我 0x03000 (?!?!)。它肯定是一个不同的数字,并且基于十六进制打印,我的数字更少(?!?!?)。

对于aUnLong,我应该收到接近数字1279272977799的数字,因此十六进制为0x129DA9C8587,而不是接收类似0x00129ffffffdaffffff8fffffff9f5c的数字。我发现有些信息很好,但它与所有 ff 混合在一起,我不知道它们来自哪里。

我保证每次都会收到 168 个字节(所以字节数是固定的)。 一开始,我考虑了结构的数据对齐,因此引入了attribute((packed))

labellbl_2 是字符串;我现在 JAVA 使用 UTF,但我不清楚在这种情况下它是如何发挥作用的。

你能帮我解决这个问题吗?

我非常感谢你。

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
};

读取使用这个简单的行进行,

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

这是发送的原始格式

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

I am trying to write in Linnux a client in C++ using boost::asio data from a socket. The server is built in Java. The issue I have now is that I cannot read correctly some piece of information from the socket. If the client is done in JAVA everything is ok.

In details the big error I have are in receiving the unsigned long and the int in the structure below. I am expectng a value for anInteger should be 0x00000005 so 5, but reading from the socket gives me 0x03000 ( ?!?! ). It is definetely a different number and based on the hexadecimal printing I have less digits( ?!?!? ).

For aUnLong I should receive something approaching to a number 1279272977799 so in hex is 0x129DA9C8587, instead a receive something like 0x00129ffffffdaffffff8fffffff9f5c. I see that some piece of information is good but it is mixed with all ffs and where I don't know where they come from.

I am guaranteed to receive each time 168 bytes ( so fixed number of bytes ).
In the beginning I though about the data alignment of my structure so I introduced attribute((packed)).

The label and lbl_2 are string; I now that JAVA uses UTF but it is not clear to me how this play in this scenario.

Can you help me with this issue?

I thank you very much.

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
};

Reading happens using this simple line

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

this is the original format sent out

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

魄砕の薆 2024-09-16 22:35:16

在常见系统上,您的结构似乎不是 168 字节。如果 long 是 4 个字节(通常在 32 位编译中),那么如果不支持 Packed,那么您的结构可能是 162 或 164。如果 long 是 8 个字节,则为 164 或 168(如果进行了填充,正如您猜测的那样,这很糟糕)。

检查程序中的 sizeof(_data) 并查看编译器告诉您的内容。

另外,您的原始格式信息令人困惑。例如,您说“字节002-010:aLong(8字节)长”,但字节2-10是九(9)个字节而不是8。是否有crc或校验和字节?

Your structure doesn't appear to be 168 bytes on common systems. If long is 4 bytes (typical in 32-bit compilation) then your struct is probably 162 or 164 if packed isn't honored. If long is 8 bytes, then 164 or 168 (if padded, which as you surmise is bad).

Check the sizeof(_data) in your program and see what the compiler tells you it is.

Also, your original format information is confusing. For example you say "byte 002-010: aLong (8 byte) long", but bytes 2-10 are NINE (9) bytes not 8. Is there a crc or checksum byte?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文