• 丰搜首页
• 文档中心
• 视频中心
• 丰搜贴吧
• 问题集锦
• 更多功能

选择显示字体大小

• 最大
• 较大
• 标准

windows sockets：阻塞

本文以及另外两篇相关文章解释 windows sockets 编程方面的一些问题。本文介绍阻塞。其他问题包含在 windows sockets：字节排序和 windows sockets：转换字符串文章中。

如果使用 casyncsocket 类或从其派生，则您需要自己管理这些问题。如果您使用 csocket 类或从其派生，则由 mfc 管理它们。阻塞

套接字可以处于“阻塞模式”或“无阻塞模式”。处于阻塞（或同步）模式时，套接字的函数直到可以完成自己的操作时才返回。这称为“阻塞”，因为函数被调用的套接字在调用返回前无法执行任何操作──它被阻塞了。例如，对 receive 成员函数的调用可能需要任意长的时间才能完成，因为它要等待发送应用程序来发送（使用 csocket 或使用带阻塞的 casyncsocke 即是如此）。如果 casyncsocket 对象处于无阻塞模式（异步操作），调用会立即返回，而当前错误代码（可使用 getlasterror 成员函数检索）为 wsaewouldblock ，它指出由于模式的原因，调用若不立即返回则将阻塞。（ csocket 永远不返回 wsaewouldblock 。该类为您管理阻塞。）

在 32 位操作系统（如 windows 95 或 windows 98）和 16 位操作系统（如 windows 3.1）下，套接字的行为是不同的。与 16 位操作系统不同，32 位操作系统使用抢占式多任务处理技术并提供多线程运行方式。在 32 位操作系统下，可以将套接字放在单独的辅助线程中。线程中的套接字可以在不妨碍应用程序中其他活动的情况下阻塞，并且不必在阻塞上花费计算时间。有关多线程编程的信息，请参见文章多线程编程。 注意: 在多线程应用程序中，可以使用 csocket 的阻塞特性来简化程序设计，而不影响用户界面的响应。通过处理主线程中的用户交互和备用线程中的 csocket 处理，可以将这些逻辑操作分开。在非多线程的应用程序中，这两个活动必须合并为单个线程来处理。这通常意味着使用 casyncsocket 以根据需要处理通信请求，或重写 csocket::onmessagepending 以在漫长的同步活动中处理用户操作。 其余的讨论针对以 16 位操作系统为目标的程序员：

通常，如果使用的是 casyncsocket ，则应避免使用阻塞操作，而应使用异步操作。例如，在异步操作中，从调用 receive 后接收到 wsaewouldblock 错误代码那一刻开始，您将一直等到 onreceive 成员函数被调用以通知您可以再次读取。通过回调套接字的适当回调通知函数（如 onreceive）来完成异步调用。

在 windows 下，阻塞调用被认为是错误的做法。默认情况下，casyncsocket 支持异步调用，而且您必须使用回调通知自己管理阻塞。另一方面，csocket 类是同步的。它抽取 windows 消息并为您管理阻塞。

有关阻塞的更多信息，请参见 windows sockets 规范。有关“on”函数的更多信息，请参见 windows sockets：套接字通知和 windows sockets：从套接字类派生。

有关更多信息，请参见：

• windows sockets：使用 casyncsocket 类
• windows sockets：使用带存档的套接字
• windows sockets：背景知识
• windows sockets：流式套接字
• windows sockets：数据文报套接字

 

关键字 本文所属关键字

相关 与本文相关文章

分类 所有文章关键字导航

标准 网站致力的规范