有关网络字节序的讨论

路小佳

谢谢指教, 希望有机会用到。
另外顺便再问一个问题，关于在网络上传输struct的问题，虽然许多代码里是直接send的， 当然这些结构都已经 #pragma pack(1)过了，但是仍有大小端的问题， 序列化的话似乎有点浪费CPU, 不知道实际项目中(比如银行)是怎么做的？

flw

原帖由 路小佳 于 2007-3-23 10:20 发表
谢谢指教, 希望有机会用到。
另外顺便再问一个问题，关于在网络上传输struct的问题，虽然许多代码里是直接send的， 当然这些结构都已经 #pragma pack(1)过了，但是仍有大小端的问题， 序列化的话似乎有点浪费CPU ...

呵呵，这个我想你没搞明白。
pack(1) 和大小端是两个概念，相互之间一点儿概念都没有。
pack(1) 是为了防止编译器优化时填充一些多余的字节进去，
而大端小端根本不是传输的问题，而是协议的内容。
你传送一个整数，用大端，而对方接收到这个整数之后，当小端去理解，那就出问题了。
解决的方法就是都用大端或者都用小端，但是到底该都用大端呢？还是该都用小端呢？
这个问题不可能每次制订协议的都去考虑一遍，也不可能由某一方说了算（合作是对等的，凭啥是你说了算），
应该由一个第三方的组织来提出，于是便有了“网络字节序”这一说，实际上网络字节序就是大端，但是我们不需要去关心这个，
只需要在发送前用 hton(s|l) 转换一下，接收后用 ntoh(s|l) 转换一下，就可以了。这个和 pack(1) 一点儿关系都没有。
以上是一般的性的概念。
至于你说的序列化会浪费 CPU，那根本就是杞人忧天，金融软件的一大特点就是稳定性高于效率，硬件配置也很高，
所以说事实上银行的协议基本上都是基于文本的。

路小佳

是我没表达清楚， 我知道pack(1)是使结构紧凑， 这只能防止网络两端在编译出来的sizeof(struct tag)不一致的情况。 大小端是没法解决的，我看的有些代码有的居然是直接发送了， 这令我疑惑， 难道作者已经假定了运行平台是大小端一致的吗？看到版主提到金融系统， 我想银行里大机比较多， 想了解一下实际是怎么做的。
嗯，既然说是基于文本的， 那就没什么疑问了。

flw

原帖由 路小佳 于 2007-3-23 10:37 发表
是我没表达清楚， 我知道pack(1)是使结构紧凑， 这只能防止网络两端在编译出来的sizeof(struct tag)不一致的情况。 大小端是没法解决的，我看的有些代码有的居然是直接发送了， 这令我疑惑， 难道作者已经假定了运 ...

我不是跟你说了嘛，htons ntohs htonl ntohl，Perl 里可以用 pack/unpack

路小佳

ok, 这些我都知道的。
我本来的意思是说在网络上直接发送结构的那些代码有两个毛病。
1. sizeof(struct XXX)可能在不同的编译器不一致。
2. 如果struct里面有int之类的成员的话， 那么两端机器的大小端如果不一致就会出问题。
虽然那些代码中已经用pack(1)解决了第一个毛病， 但是第二个毛病依然存在。
解决第二个毛病可以用序列化， 或者对特定成员转换字节序。或者干脆不理。
有些嵌入式的程序就是没理会这个问题， 而我想问的是银行的系统是不是也是这样。
嗯， 罗嗦了点， 还是谢谢版主的答案。

[ 本帖最后由 路小佳 于 2007-3-23 10:53 编辑 ]

月魔

我是鹦鹉，我是鹦鹉：
下面的话意思是，如果你要发送、接收就要遵从协议


由一个第三方的组织来提出，于是便有了“网络字节序”这一说，实际上网络字节序就是大端，但是我们不需要去关心这个，
只需要在发送前用 hton(s|l) 转换一下，接收后用 ntoh(s|l) 转换一下，就可以了。这个和 pack(1) 一点儿关系都没有。
以上是一般的性的概念。

战鹰

字节顺序的问题一般在协议文档当中是有约定的，写程序的时候注意一下就可以了。

xiaochongs

在网络上传struct是有问题的，
应该传字节数组

cenziboy

回复 8# xiaochongs

您的意思是碰到结构体就不传了？

不是的吧 ！！

flw

hton(s|l) 后可传，对端再 ntoh(s|l) 就解开了