实施问题.. [英] implementation issue ..
问题描述
我在不同的
平台上进行沟通时遇到了端点问题。
所以我已经建议/提示（来自其中一个新闻组 - 无法回答哪些）b / b
召回哪一种方法（或两个或三个）看似合理
并且基于遇到的问题以及如何处理它们
这种情况。
其中一个 - 我正在调查的那个 - 如下：
出于讨论目的，考虑将在
两个平台（a和b）之间传输的结构。平台a是小端。 b是big endian。
示例结构类似于。
//
typedef double tag_word;
struct t2_data
{
tag_word tag_word_;
bool lvt_enable：1;
bool范围：1;
bool valid_mst：1;
//更多
};
struct t2_status
{
tag_word tag_word_;
bool lvt_status：1;
bool range_status：1;
bool msg_is_valid：1;
unsigned int：2;
unsigned int：4;
//更多
};
struct msg_header
{
unsigned int msg_size;
unsigned int msg_id;
unsigned int msg_count;
unsigned int msg_chksum;
};
/ / later
struct platform_a_to_b // l ittle endian（平台a）到big endian
（平台b）
{
msg_header header;
t2_data t2_data_;
};
//稍后
struct platform_b_to_a // big endian（平台b）到小端
（平台a）
{
msg_header标题;
t2_status t2_stat;
};
正在调查的方法涉及分配一个足够大的缓冲区来保存正在传输/接收的消息。所以现在：对于
收到消息（IOW a从b接收，反之亦然），我会：
1.分配一个unsigned char缓冲区大到足以容纳消息。
2.将消息读入缓冲区。
3.转换数据的字节序（如有必要）。
4.从缓冲区加载模型结构的每个成员。
现在我被告知消息的传递顺序与项目的顺序相反
1到4，但这让我很困惑。为什么？随着少数调整，我看到了
反向订单：
1a。分配一个大到足以容纳消息的unsinged char缓冲区。
这假定缓冲区尚未分配。
2a。加载模型结构INTO的每个成员（在这种情况下，让我们从结构中获取
信息并放入缓冲区）缓冲区。
3a。转换数据的字节序。
项目2a对我来说似乎有缺陷。我可以将一个结构转储一个字节缓冲区并通过一个线路发送它的想法似乎是一个坏主意，因为
显而易见的原因。也就是说，我不能保证这两个plarforms
pack以相同的方式结构化，这会导致比b / b
解决的更多头痛。也就是说，我很困惑这个''byte''缓冲区
方法是如何工作的。
对于那些使用过这种方法的人来说有代码可以工作，如果它可以分享（转换代码+示例结构）我会说它。
阅读_ACTUAL_代码帮助我''得到我的围绕事物''。
另一件事：
虽然可以说
a字段的每字节数的要求是在文件中固定了，上述结构中的类型，即bool - 指定
需要重新访问。在处理结构和位字段时，我被建议遵循以下
协议：
1.仅使用double，unsigned int（32位）和unsigned char。
2.如果我需要bool take和int，如果我必须考虑平台使用
不同的bool类型大小。
3.按顺序使用double int和char（数组）。
4.使char arr'的大小为4的倍数。（8的更好的倍数）。
我将重新访问/调查这种方法。
I''m faced with endian issues during communication across different
platforms.
So I''ve recommendations/tips (from one of these newsgroups - cant
recall which) on an approach (or two or three) that seems reasonable
and is based on issues that were encountered and how to handle them in
this situation.
One of which - the one I''m currently investigating - is as follows:
For discussion purposes consider atruct that''ll be transmitted between
two plaforms (a and b). Platform a is little endian. b is big endian.
A sample struct is akin to.
//
typedef double tag_word;
struct t2_data
{
tag_word tag_word_;
bool lvt_enable : 1;
bool range : 1;
bool valid_mst : 1;
// more
};
struct t2_status
{
tag_word tag_word_;
bool lvt_status : 1;
bool range_status : 1;
bool msg_is_valid : 1;
unsigned int : 2;
unsigned int : 4;
// more
};
struct msg_header
{
unsigned int msg_size;
unsigned int msg_id;
unsigned int msg_count;
unsigned int msg_chksum;
};
// later
struct platform_a_to_b // little endian (platform a) to big endian
(platform b)
{
msg_header header;
t2_data t2_data_;
};
// later
struct platform_b_to_a // big endian (platform b) to little endian
(platform a)
{
msg_header header;
t2_status t2_stat;
};
The approach under investigation involves allocation of a buffer large
enough to hold the message being transmitted/received. So now: For
the receipt of message (IOW a receives from b or vice versa), I''ll:
1. Allocate an unsigned char buffer large enough to hold the message.
2. Read the message into the buffer.
3. Convert the endianism of the data(if necessary).
4. Load each member of the model struct from the buffer.
Now I''m told that transmittal of messages is the reverse order of items
1 to 4, but that puzzles me. Why? With a ''few'' tweaks heres the
reverse order as I see it:
1a. Allocate a unsinged char buffer large enough to hold the message.
This assumes a buffer hasn''t already been allocated.
2a. Load each member of the model struct INTO (in this case lets take
the information from the struct and put into the buffer) the buffer.
3a. Convert the endianism of the data.
Item 2a seems flawed to me. The idea that I could just dump a struct
ino a byte buffer and send it across a wire seems like a bad idea, for
obvious reasons. Namely, I''m not guaranteed that the two plarforms
pack structs the same way and that would cause more headaches than it
will solve. That said, I''m puzzled about how this ''byte'' buffer
approach works.
For those who''ve used this approach and have code that works, if its
possible to share (conversion code + sample struct) I''d appreaciate it.
Perusing _ACTUAL_ code assists me in ''getting my head around things''.
One other thing:
While it can be said that the requirements per the number of bytes for
a field is ''fixed'' in a document, the types, - namely bool - specified
in the structs above need revisiting. I''ve been advised to follow
protocol below when dealing with structs and bit fields:
1. use only double, unsigned int (32 bits) and unsigned char.
2. if I need bool take and int, if I have to consider platforms using
different bool type sizes.
3. use double int and char (arrays) in that order.
4. make char arr''s size a multiple of 4. (better multiple of 8).
I''ll be re-visiting/investigating this approach.
推荐答案
ma ****** @ pegasus.cc.ucf.edu 写道：
ma******@pegasus.cc.ucf.edu wrote:
出于讨论目的，考虑将在两个平台（a和b）之间传输的结构。平台a是小端。 b是大端。
示例结构类似于。
位域打包是实现定义的。我已经看到订单变化了
甚至是相同字节排序的机器。
4.从缓冲区加载模型结构的每个成员。
我想这取决于你的意思。
3a。转换数据的字节序。
我会将此与4步合并，因为我不确定尝试
单独执行它们是有效的。
项目2a对我来说似乎有缺陷。由于显而易见的原因，我可以将一个结构转储到字节缓冲区并通过线路发送它的想法似乎是一个坏主意。也就是说，我不能保证这两个plarforms包装结构的方式相同，并且会导致比它解决的更多头痛。也就是说，我很困惑这个字节缓冲区如何工作。
For discussion purposes consider atruct that''ll be transmitted between
two plaforms (a and b). Platform a is little endian. b is big endian.
A sample struct is akin to.
Bitfield packing is implementation defined. I''ve seen the order vary
even machines of the same byte ordering.
4. Load each member of the model struct from the buffer.
I guess that depends on what you mean by this.
3a. Convert the endianism of the data.
I would combine this with step with 4 as I''m not sure it''s valid to try
to do them separately.
Item 2a seems flawed to me. The idea that I could just dump a struct
ino a byte buffer and send it across a wire seems like a bad idea, for
obvious reasons. Namely, I''m not guaranteed that the two plarforms
pack structs the same way and that would cause more headaches than it
will solve. That said, I''m puzzled about how this ''byte'' buffer
approach works.
你是对的，但它''所有这些都在上面的步骤4中处理。如果你总是在一个已知的编码中将一个双精度转换为8个字节，并且在某个字节序列中加入一个b / b
，那么它应该可以工作......你''基本上只是将结构复制到字节流而不仅仅是b $ b。但是对它执行你自己的
编码。
You''re correct, but it''s all dealt with by step 4 above. If you always
convert a double to 8 bytes in a known encoding, and the bools into a
certain sequence of bytes, then it should work...you''re essentially
not just "copying the struct to the bytestream" but enforcing your own
encoding on it.
ma ****** @ pegasus.cc.ucf.edu 写道：
我在不同的通信过程中遇到了端点问题
平台。
所以我有一些建议/提示（来自其中一个新闻组 - 不能回想起哪一个）对一种似乎合理的方法（或两三个）
其中一个 - 我正在调查的那个 - 如下：
出于讨论目的，考虑将在两个平台（a和b）之间传输的结构。平台a是小端。 b是大端。
示例结构类似于。
//
typedef double tag_word;
struct t2_data
{
tag_word tag_word_;
bool lvt_enable：1;
bool范围：1;
bool valid_mst：1;
//更多
};
struct t2_status
{
tag_word tag_word_;
bool lvt_status：1;
bool range_status：1;
bool msg_is_valid：1;
unsigned int：2;
unsigned int：4;
// more
};
struct msg_header
{
unsigned int msg_size;
unsigned int msg_id;
unsigned int msg_count;
unsigned int msg_chksum;
};
//稍后
struct platform_a_to_b // little endian （平台a）到big endian
（平台b）
{
msg_header标题;
t2_data t2 _data_;
};
//稍后
struct platform_b_to_a // big endian（平台b）到小端
（平台a）
{
msg_header标题;
t2_status t2_stat;
};
正在调查的方法涉及分配足够大的缓冲区来保存正在传输/接收的消息。所以现在：对于
收到消息（IOW a从b接收或反之亦然），我会：
1.分配一个足够大的无符号字符缓冲区来保存消息。
2.将消息读入缓冲区。
3.转换数据的字节序（如有必要）。
4.从缓冲区加载模型结构的每个成员。
现在我被告知消息的传送顺序与项目的顺序相反，但是这让我很困惑。为什么？随着少数调整，我看到了相反的顺序：
1a。分配一个大到足以容纳消息的unsinged char缓冲区。
这假定缓冲区尚未分配。
2a。加载模型结构INTO的每个成员（在这种情况下，让我们从结构中获取信息并放入缓冲区）缓冲区。
3a。转换数据的字节序。
项目2a对我来说似乎有缺陷。由于显而易见的原因，我可以将一个结构转储到字节缓冲区并通过线路发送它的想法似乎是一个坏主意。也就是说，我不能保证这两个plarforms包装结构的方式相同，并且会导致比它解决的更多头痛。也就是说，我很困惑这个字节缓冲区如何工作。
对于那些已经使用过这种方法并且代码有效的人，如果它<可以分享（转换代码+示例结构）我会对它进行说明。
阅读_ACTUAL_代码可以帮助我理解事物。
另外一个事情：
虽然可以说一个字段的字节数要求在一个文件中是固定的，但是类型，即bool - 指定了
上面的结构需要重新审视。在处理结构和位域时，我被建议遵循以下
协议：
1.仅使用double，unsigned int（32位）和unsigned char。
2.如果我需要bool take和int，如果我必须考虑使用
不同bool类型大小的平台。
3.按顺序使用double int和char（数组）。
4。使char arr'的大小为4的倍数。（8的更好的倍数）。
我将重新访问/调查这种方法。
I''m faced with endian issues during communication across different
platforms.
So I''ve recommendations/tips (from one of these newsgroups - cant
recall which) on an approach (or two or three) that seems reasonable
and is based on issues that were encountered and how to handle them in
this situation.
One of which - the one I''m currently investigating - is as follows:
For discussion purposes consider atruct that''ll be transmitted between
two plaforms (a and b). Platform a is little endian. b is big endian.
A sample struct is akin to.
//
typedef double tag_word;
struct t2_data
{
tag_word tag_word_;
bool lvt_enable : 1;
bool range : 1;
bool valid_mst : 1;
// more
};
struct t2_status
{
tag_word tag_word_;
bool lvt_status : 1;
bool range_status : 1;
bool msg_is_valid : 1;
unsigned int : 2;
unsigned int : 4;
// more
};
struct msg_header
{
unsigned int msg_size;
unsigned int msg_id;
unsigned int msg_count;
unsigned int msg_chksum;
};
// later
struct platform_a_to_b // little endian (platform a) to big endian
(platform b)
{
msg_header header;
t2_data t2_data_;
};
// later
struct platform_b_to_a // big endian (platform b) to little endian
(platform a)
{
msg_header header;
t2_status t2_stat;
};
The approach under investigation involves allocation of a buffer large
enough to hold the message being transmitted/received. So now: For
the receipt of message (IOW a receives from b or vice versa), I''ll:
1. Allocate an unsigned char buffer large enough to hold the message.
2. Read the message into the buffer.
3. Convert the endianism of the data(if necessary).
4. Load each member of the model struct from the buffer.
Now I''m told that transmittal of messages is the reverse order of items
1 to 4, but that puzzles me. Why? With a ''few'' tweaks heres the
reverse order as I see it:
1a. Allocate a unsinged char buffer large enough to hold the message.
This assumes a buffer hasn''t already been allocated.
2a. Load each member of the model struct INTO (in this case lets take
the information from the struct and put into the buffer) the buffer.
3a. Convert the endianism of the data.
Item 2a seems flawed to me. The idea that I could just dump a struct
ino a byte buffer and send it across a wire seems like a bad idea, for
obvious reasons. Namely, I''m not guaranteed that the two plarforms
pack structs the same way and that would cause more headaches than it
will solve. That said, I''m puzzled about how this ''byte'' buffer
approach works.
For those who''ve used this approach and have code that works, if its
possible to share (conversion code + sample struct) I''d appreaciate it.
Perusing _ACTUAL_ code assists me in ''getting my head around things''.
One other thing:
While it can be said that the requirements per the number of bytes for
a field is ''fixed'' in a document, the types, - namely bool - specified
in the structs above need revisiting. I''ve been advised to follow
protocol below when dealing with structs and bit fields:
1. use only double, unsigned int (32 bits) and unsigned char.
2. if I need bool take and int, if I have to consider platforms using
different bool type sizes.
3. use double int and char (arrays) in that order.
4. make char arr''s size a multiple of 4. (better multiple of 8).
I''ll be re-visiting/investigating this approach.
或者只是发送/ rcv ascii中的数据;或者使用xml。
如果每个结构都有读/写方法（serialize（）等）
将结构内容写入/读取为文本大大
简化平台间的数据xfer。
将格式化的二进制数据（结构等）从
转移到另一个拱门几乎不是一个好主意。
问候，
拉里
-
反垃圾邮件地址，将每个''X''更改为''。''直接回复。
Or just send/rcv the data in ascii; or use xml.
If each struct has read/write methods (serialize(), etc)
that write/read the structs contents as text it greatly
eases data xfer across platforms.
Transferring formatted binary data (structs, etc) from
one arch to another is almost never a good idea.
Regards,
Larry
--
Anti-spam address, change each ''X'' to ''.'' to reply directly.
Ron，感谢您的信息。让我确保我已经知道了这个问题。
这个。让我们假设playform''a''本地语言是32位。让我们假设
平台'''''的本地语言是16位。
同样的故事：a是小端b很大。让我们进一步假设我们
有
结构测试{
unsinged int some_value;
} ;
让我们假设//稍后：
test my_test; my_test.some_value = 655394;
现在发送给b，但在发送之前。 a需要将'b $ b some_value''加载''到一个字节缓冲区。 （现在我希望我可以在usenet中画画
世界）。我们有4个字节来表示some_value。
现在：
字节缓冲区
--------- ----- -------------- --------------
--------- -----
字节1字节2字节3字节4
-------------- ------- ------- --------------
--------------
Endian转换
传输
b收到。 b'的母语是16位。我想我在这里看到了需要什么才能发生什么？但是要将从
a发送的4个字节映射到测试结构中需要做什么？你的答案可能会帮助我回答所有
我脑中产生的情景。
Ron, thanks for the info. Let me make sure I''ve got my head around
this. Lets assume playform ''a'' native tongue is 32 bits. Lets assume
platform ''b''s'' native tongue is 16 bits.
Same story: a is little endian b is big. Lets further assume we
have a
struct test {
unsinged int some_value;
};
Lets assume // later :
test my_test; my_test.some_value = 655394;
Now a transmits to b, but prior to transmitting. a will need to ''load''
some_value into a byte buffer. ( Now I wish I could draw in usenet
world). We have 4 bytes to represent some_value.
So now:
Byte Buffer
-------------- -------------- --------------
--------------
byte 1 byte 2 byte 3 byte 4
-------------- -------------- --------------
--------------
Endian conversion
Transmit
b receives. b''s native tongue is 16 bits. I think I see what needs to
happen here but what would ''b'' need to do to map the 4 bytes sent from
a into the test struct? Your answer will perhaps help me ''answer'' all
the scenarios I''ve generated in my head.
这篇关于实施问题..的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
