我知道在网络上,大多数整数都是大端格式。
但是为什么应用程序的负担是在像sockaddr_in
内核这样的结构中进行字节交换而不是在所有底层工作实际发生的地方?如果用户空间 API 更与平台无关并且不应该处理这个问题,那将更有意义。
为什么伯克利套接字 API 是这样设计的?
我知道在网络上,大多数整数都是大端格式。
但是为什么应用程序的负担是在像sockaddr_in
内核这样的结构中进行字节交换而不是在所有底层工作实际发生的地方?如果用户空间 API 更与平台无关并且不应该处理这个问题,那将更有意义。
为什么伯克利套接字 API 是这样设计的?
原因可能是历史原因。
套接字 API 是在Sun-3 (MC68030) 和Sun-4 (Sparc) 工作站成为王者时发明的(在 1980 年代) 。这些(按照今天的标准很慢)处理器的字节序很重要。
我忘记了细节,可能已经为某些PDP-11或VAX-780发明了 BSD 套接字约定。
但是为什么应用程序的负担是在像 sockaddr_in 这样的结构中而不是内核中进行字节交换
可能是因为在 1980 年代,您不希望计算机(比您的手机慢一千倍)在内核领域花费太多(不间断)时间。
这个问题真的应该在https://retrocomputing.stackexchange.com/上提出(它的答案在一些 1980 年代 Unix 内核的源代码中)
我能想到的唯一技术优势是它允许应用程序进行一次转换并缓存它。
然后,对于无数的 UDP 调用sendto()
,或者你有什么,重新排序的必要地址被提供给操作系统,操作系统可以直接将其复制到传出的网络数据包中。
在内核中执行此操作的替代方案将要求每次调用都sendto()
将应用程序所知道的内容一遍又一遍地作为相同的地址,并且每次都重新转换它。
由于sendto()
从中受益,他们让 API 的其余部分以相同的方式工作。