【问题标题】:Why are there WSA pendants for socket(), connect(), send() and so on, but not for closesocket()?为什么socket()、connect()、send()等有WSA挂件,closesocket()没有?
【发布时间】:2011-03-16 09:58:13
【问题描述】:

我将尝试用几个例子来解释我的意思:

  • socket() -> WSASocket()
  • connect() -> WSAConnect()
  • send() -> WSASend()
  • sendto() -> WSASendTo()
  • recv() -> WSARecv()
  • recvfrom() -> WSARecvFrom()
  • ...
  • closesocket() -> WSA???()

这没什么大不了的,但仍然让我头疼。

【问题讨论】:

  • closesocket 不是 close 的 Windows 版本吗?
  • 没错,在大多数操作系统上它只是close
  • 感谢您的信息。我不知道。
  • 只是想补充一点,bind() 也没有WSA* 相等。

标签: c++ winapi sockets winsock


【解决方案1】:

这是写在 MSDN 文档中的:

Renamed Functions

在两种情况下,有必要重命名 Berkeley 套接字中使用的函数,以避免与其他 Microsoft Windows API 函数发生冲突。

关闭和关闭套接字

在 Berkeley Sockets 中,套接字由标准文件描述符表示,因此 close 函数可用于关闭套接字以及常规文件。虽然 Windows Sockets 中没有任何东西可以阻止实现使用常规文件句柄来识别套接字,但也没有什么需要它。在 Windows 上,必须使用 closesocket 例程关闭套接字。在 Windows 上,使用 close 函数关闭套接字是不正确的,这样做的效果在本规范中未定义。

Ioctl 和 Ioctlsocket/WSAIoctl

各种 C 语言运行时系统将 IOCTL 用于与 Windows 套接字无关的目的。因此,ioctlsocket 函数和 WSAIoctl 函数被定义为处理由 Berkeley Software Distribution 中的 IOCTLfcntl 执行的套接字函数。 p>

【讨论】:

    【解决方案2】:

    要理解这一点,您必须意识到 Winsock 是在 1990 年代初期创建的,当时 Windows 3.x 恐龙在地球上漫游。

    Windows 套接字(“Winsock”)API 反映了大多数 BSD 套接字 API:两者都提供给定的功能,都做同样的事情。所以,socket() 是两个 API 下的同一个调用。地方有细微差别,但没有比其他基于 BSD 套接字的系统(如 Linux 和 OS X)在网络编程上的差异更大的了。

    除了实现通用的基础 API 之外,Winsock API 还提供了许多 BSD 套接字的扩展。许多函数的名称与原始函数相似,但带有 WSA 前缀和驼峰式大小写。这些是原始功能的纯粹扩展版本,而不是它们的替代品。您可以根据是否需要扩展功能以及您的程序是否必须可移植到仅提供 BSD 套接字 API 的系统来选择使用哪一个。例如,WSASocket() 采用与 socket() 相同的参数以及与其他 Winsock 扩展有关的三个附加参数。如果您不需要扩展,调用socket() 并没有真正的惩罚,而且您还可以获得可移植性好处。

    除了这些简单的扩展之外,还有一些没有直接等效 BSD 的 Winsock 扩展,例如 WSAAsyncSelect()。与 Unixy 系统的程序相比,这些通常与 Windows 程序的编写方式不同有关。在这种特殊情况下,WSAAsyncSelect() 的存在是为了更容易编写使用套接字的单线程 GUI 程序,而网络 I/O 不会阻塞 GUI,或者反之亦然。这在今天很有用,但对于 Winsock 在 Windows 3.1 时代的成功绝对至关重要,因为它没有线程或其他有用的多处理和 IPC 机制。

    这样就只剩下closesocket()ioctlsocket() 这样的怪人了。

    closesocket() 与 POSIX/Unix 下的close(2) 相同,只是它只接受套接字,而不接受文件句柄。这是更名的部分原因,但真正的原因来自我在上面提到的 1990 年代早期的历史问题。在那些日子里,一些 Windows 编译器——比今天有 moreavailablethen——包括 POSIX API 等价物,以方便将代码从其他平台移植到 Windows。这些功能非常有限,并且不包括套接字支持,但是,close() 函数名称当时在 Windows 上被认为是“采用”的。这不再是真的,但 Winsock 是其历史的产物,现在无法改变。

    ioctlsocket()ioctl() 的故事相似。一个很大的区别是ioctlsocket() 在 Windows 上的功能与ioctl() 在 Unix 系统上的功能相比受到了很大的限制。它的存在只是为 Windows 提供一些与网络相关的设施,最初的 Winsock 创建者认为这些设施在 BSD 套接字 API 中很有用。多年来,您可以在 Unixy 系统上使用套接字和 ioctl() 而无法使用 ioctlsocket() 执行的大部分操作都已通过其他 API 添加到 Windows,WSAIoctl() 就是其中之一。

    我为Winsock Programmer's FAQ(我保留)写了一篇关于“The History of Winsock”的文章,其中详细介绍了所有这些。另一篇相关文章是“BSD Sockets Compatibility”。

    【讨论】:

    • 我很惊讶这个有见地的答案没有得到更多的支持。来自我的 +1。
    【解决方案3】:

    为了完整起见,人们应该注意到,无论是关于网络、文件、时间/日期还是 ANSI C/POSIX API 的任何其他部分,微软都花费了大量精力来确保其专有几代 Windows API 与 Unix API(早在 Windows 之前就存在)不兼容。

    微软在 HTML (IE)、HTTP (IIS)、OpenDocuments (MS-Word) 等中使用了相同的策略,所以通常的借口是它是偶然的(或者只是出于“创新”的愿望)值得怀疑。

    看看有多少 C# 是 Java 的(坏)副本 - 同时设法完全不兼容(函数名称非常接近,如果不相同,但参数的数量 - 或它们的顺序 - 是不同的)。

    现在你知道为什么你首先要问这个问题了。

    【讨论】:

    • “看看有多少 C# 是 Java 的(坏)副本——同时设法完全不兼容”——同时看看甲骨文对谷歌做了什么重新实现了具有完全向后兼容性的 Java。 2010 年开始的甲骨文诉讼,到 2017 年仍未结束……微软已经被 Java 烧过一次——他们吸取了教训。
    【解决方案4】:

    closesocket 仅在 Windows 上可用,但我不确定他们为什么不遵循 WSA 约定。如果它真的让您感到困扰,尽管您可以制作自己的调用 closesocket 的包装器。

    正如WSASocket 中提到的,应该调用closesocket。

    【讨论】:

    • 这确实让我有点困扰,这就像我使用的唯一一个在 CamelCase 中没有名字的函数。 :(
    • @Oliver Baur:我承认这很奇怪。不一致的命名约定可能是一个真正的痛苦。
    • IIRC WSA* 名称的原因是函数参数与相应的套接字 API 不同。如果有人向 API 添加新参数,它会破坏使用 socket() 的程序。
    猜你喜欢
    • 2018-06-27
    • 1970-01-01
    • 1970-01-01
    • 2022-01-03
    • 1970-01-01
    • 2021-05-09
    • 1970-01-01
    • 2018-12-19
    • 2012-10-14
    相关资源
    最近更新 更多