【问题标题】:Blocking sockets v/s non-blocking sockets in multi-threaded single server multiple client application [closed]多线程单服务器多客户端应用程序中的阻塞套接字与非阻塞套接字[关闭]
【发布时间】:2013-05-13 06:07:13
【问题描述】:

我一直在研究服务器客户端应用程序,其中服务器将一次为(sendto + receivefrom)“x”个客户端提供服务。为此,我在服务器端创建了“x”个线程,以便每个线程都指定给一个客户端。每个线程内部都有一个特定的套接字供其客户端使用。我正在考虑使这些套接字成为非阻塞的,但现在我认为在每个线程中使用阻塞套接字是一个更好的主意。阻塞 Socket 持续等待接收数据,每当需要发送任何内容时,都会调用 sendto()。在这种情况下使用阻塞套接字是一种好方法还是应该使用非阻塞套接字?
等待帮助!!!

【问题讨论】:

  • 如果每个连接都有一个专用线程,则实际上不需要使套接字非阻塞。另一方面,你应该注意不要有太多的连接,因为太多的线程可能会严重降低系统性能(CPU 在线程之间交换的工作比“真正的”工作要多)。
  • 如果您的设计是 1 个线程/套接字,并且线程的基本目的是为网络请求提供服务……那么阻塞是绝对最好的方法。恕我直言...
  • 如果您希望能够异步发送数据,同时等待接收数据,那么不,您不能使用阻塞套接字。如果你开始做例如selectpolling 那个时候在单线程的单连接上做真的没啥用,那不如把更多的连接拉到单线程,少线程。
  • 非阻塞套接字仅在您希望一个线程服务多个连接时才有用。使用非阻塞套接字和轮询/选择循环意味着您的线程在等待新连接时不会处于空闲状态。
  • 主要的阻塞套接字问题是recv 函数在接收到一些数据之前不会返回。但是,这可以通过从另一个线程关闭套接字来解决 - recv 立即返回失败。有时我使用阻塞套接字,因为它们具有简单的编程接口。

标签: c windows sockets winapi network-programming


【解决方案1】:

我想使这些套接字成为非阻塞的,但现在我认为在每个线程中使用阻塞套接字是一个更好的主意。阻塞 Socket 持续等待接收数据,每当需要发送任何内容时,都会调用 sendto()。在这种情况下使用阻塞套接字是一种好方法还是应该使用非阻塞套接字?

我同意。除非您期望有数十万个连接,否则我认为没有理由超越线程和阻塞 I/O。 select() 和朋友们是在阻塞 I/O 的替代方案是另一个进程而不是另一个线程的时代设计的。

【讨论】:

    猜你喜欢
    • 2017-04-18
    • 1970-01-01
    • 1970-01-01
    • 2012-06-13
    • 1970-01-01
    • 1970-01-01
    • 2010-10-31
    • 2013-10-15
    • 1970-01-01
    相关资源
    最近更新 更多