WinSock最佳accept()做法

发布于 2024-08-31 10:43:09 字数 189 浏览 3 评论 0 原文

想象一下,您有一台服务器一次只能处理一个客户端。服务器使用 WSAAsyncSelect 来接收新连接的通知。在这种情况下,处理FD_ACCEPT消息的最佳方式是什么:

A>立即接受连接尝试,但将客户端排队直到轮到它?

B>在我们完成当前连接的客户端的服务之前不接受下一次连接尝试?

大家觉得什么效率最高?

Imagine you have a server which can handle only one client at a time. The server uses WSAAsyncSelect to be notified of new connections. In this case, what is the best way of handling FD_ACCEPT messages:

A > Accept the connection attempt right away but queue the client until its turn?

B > Do not accept the next connection attempt until we are done serving the currently connected client?

What do you guys think is the most efficient?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

无所谓啦 2024-09-07 10:43:09

在这里,我描述了我所知道的这两种选择的缺点。希望这可以帮助您做出决定。

A)

  • 在新的客户端连接上,它可能会发送大量数据,使您的接收缓冲区变满,从而导致传输不必要的数据包(请参阅这个)。如果您不打算从客户端接收任何数据,shutdown 在该套接字上接收,因此如果客户端在此之后发送任何数据,连接将被重置。此外,如果您的协议有严格的规则,请断开客户端。
  • 如果连接空闲时间过长,系统可能会断开连接。要解决此问题,请使用 setsockopt 设置 <每个客户端套接字上的 href="http://msdn.microsoft.com/en-us/library/ee470551(v=VS.85).aspx" rel="nofollow noreferrer">SO_KEEPALIVE 。

B)

  • 如果您不接受 连接一定时间后(我猜默认是60秒),它会超时。在正常(或最常见)情况下,这表明服务器过载,因此无法及时应答。但是,如果客户端也是您设计的,请将套接字设置为非阻塞,尝试连接,然后根据您的意愿管理超时。

Here I describe the cons that I'm aware for both options. Hopefully this might help you decide.

A)

  • Upon a new client connection, it could send tons of data making your receive buffer become full, which causes unnecessary packets to be transmitted (see this). If you don't plan to receive any data from the client, shutdown receiving on that socket, thus if the client sends any data after that, the connection is reset. Moreover, if your protocol has strict rules, disconnect the client.
  • If the connection stays idle for too long, the system might disconnect it. To solve this, use setsockopt to set SO_KEEPALIVE on each client socket.

B)

  • If you don't accept the connection after a certain period (I guess the default is 60 seconds), it will timeout. In a normal (or most common) situation this indicates the server is overloaded, thus unable to answer in time. However, if the client is also designed by you, make the socket non-blocking, try to connect, then manage the timeout as you wish.
失退 2024-09-07 10:43:09

问问自己:您希望另一端的用户体验如何?你想让他们被困住吗?你想让他们超时吗?您希望他们收到礼貌的消息吗?

Ask yourself: what do you want the user experience to be at the other end? Do you want them to be stuck? Do you want them to time out? Do you want them to get a polite message?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文