从阻塞套接字切换到非阻塞套接字有什么好处？

Question

我们有一个使用Delphi 2010和Indy 10开发的应用服务器.该服务器每秒接收超过50个请求并且运行良好.但在某些情况下,在我看来,Indy非常模糊.它们的组件很好,但有时我发现自己只是为了理解一个简单的事情而深入研究源代码.Indy缺乏良好的文档和良好的支持.
我遇到的最后一件事对我来说是一个大问题:我必须检测客户端何时正常断开连接(例如,当客户端崩溃或关闭时.不告诉服务器它将断开连接)并且indy无法去做.如果我想要,我将不得不开发心跳,汇集或TCP保持活动等算法.我不想花更多的时间来做一个,至少我认为,组件工作.经过一些研究,我发现这不是Indy的错,但这是所有阻塞套接字组件的问题.

现在我真的想把服务器的核心改成另一个好的套件.我必须承认我倾向于使用非阻塞套接字.基于此,我有一些问题:

• 从阻塞套接字切换到非阻塞套接字有什么好处？
• 我是否能够检测到客户端断开连接(非正常)？
• 什么组件套件有最好的产品？我所说的最好的产品是:快速,良好的支持,良好的工具和易于实施.

我知道这一定是一个主观问题,但我真的很想听到你的意见.我的第一个问题是我最关心的问题.我不在乎我是否需要支付100,500,1000,10000美元,但我想要一个完整的解决方案.现在,我正在考虑Ip*的工作原理.

编辑

我觉得有些人不明白我想要什么.我不想创建自己的套接字.我已经使用插座很长一段时间了,我厌倦了它.真.

非阻塞套接字可以检测客户端断开连接.这是事实,它在整个互联网上都有很好的文档.非阻塞套接字始终检查套接字状态是否有新的传入数据,并且可以检测到套接字无效.这不是心跳算法.在客户端使用心跳算法,它会定期向服务器发送数据包(也称为保持活动状态)以告知它仍处于活动状态.

编辑

我不是说清楚.也许是因为英语不是我的主要语言.我并不是说可以在不尝试从套接字发送或接收数据的情况下检测掉线连接.我所说的是每个非阻塞套接字都可以这样做,因为它们不断尝试从套接字读取新的传入数据.为什么这么难理解？如果你们下载并运行ip*工程演示,特别是echoserver和echoclient(都使用TCP),你可以自己测试.我已经测试了它,它的工作方式与我预期的相同.即使您在非阻塞模式下使用旧的TCPSocketServer和TCPSocketClient,您也会看到我的意思.

Answer 1

"从阻塞套接字切换到非阻塞套接字有什么好处？
我能否检测到客户端断开连接(非优雅)？ "

这个问题只是我的两分钱 - 我不是插座专家,但我确实对他们有很多经验.如果我弄错了,我相信有人会纠正我...... :-)

我假设,由于您使用每秒50个连接的阻塞套接字运行服务器,因此您可以使用线程机制来处理客户端请求.如果是这样,你就不会从非阻塞插座获得任何东西.相反 - 您必须根据主线程中从非阻塞套接字触发的事件,将您的服务器逻辑更改为事件驱动,或者使用常量轮询来了解您的套接字是什么.

非阻塞套接字无法检测到客户端断开连接而不通知阻塞套接字可以 - 它们没有心灵感应功能......客户端和服务器之间TCP/IP"对话"的性质是相同的 - 阻塞和非阻塞-blocking仅针对您的应用程序与执行"对话"的套接字连接的交互.

如果需要清除死连接,则需要在套接字上实现心跳或超时机制(我从未见过不支持超时的现代套接字实现).

Answer 2

从阻塞套接字更改为非阻塞套接字有什么好处？

根据我的经验，提高了速度，可用性和吞吐量。我有一个IndySockets客户端，它每秒大约接收15个请求，而当我直接进入异步套接字时，吞吐量增加到每秒大约90个请求（在同一台机器上）。在具有30 Mbit连接的数据中心服务器上的另一项基准测试中，我每秒能够收到300多个请求。

我能否检测到客户端断开连接（非正常）？

这是我尚未尝试的一件事，因为我的所有代码都在客户端。

哪个组件套件具有最佳产品？最好的产品，我的意思是：快速，良好的支持，良好的工具和易于实施的产品。

您可以在几天之内建立自己的套接字客户端，它可以非常健壮和快速……比我所见过的大多数东西都快得多。随时查看我的异步套接字客户端：http : //codesprout.blogspot.com/2011/04/asynchronous-http-client.html

更新：（
根据Mikey的评论）

我想请您就NBS如何提高吞吐量（相对于正确设计的BS服务器）进行一般性的技术解释。

让我们以一个高负载服务器为例：假设您的服务器在任何给定时间都可以处理1000个连接，如果使用阻塞套接字，则必须创建1000个线程，即使它们大部分是空闲的，CPU仍然会花费很多。时间上下文切换。随着客户端数量的增加，您必须增加线程数量才能跟上步伐，CPU不可避免地会增加上下文切换。对于使用阻塞套接字建立的每个连接，都将招致产生新线程的开销，最终您将招致在线程之后进行清理的开销。当然，首先想到的是：为什么不使用ThreadPool，则可以重用线程并减少创建/清理线程的开销。

这是在Windows上处理此问题的方式（因此具有.NET连接）：可以，但是使用.NET ThreadPool会注意到的第一件事是它具有两种类型的线程，并且并非巧合：用户线程和I / O完成端口线程。异步套接字使用IO完成端口，这些端口“允许单个线程在不同的句柄上同时执行I / O操作，甚至在同一句柄上同时执行读写操作。”（1）I / O完成端口线程是经过专门设计的处理I / O以更有效的方式比你永远不会将能够实现，如果你在线程池使用的用户线程，除非你写你自己的内核模式驱动程序。

“完成端口使用某种特殊的巫毒来确保一次只能运行特定数量的线程-如果一个线程在内核模式下阻塞，它将自动启动另一个线程。”（2）

还具有其他优点：“除了重叠套接字I / O的非阻塞优点之外，另一个优点是更好的性能，因为您为每个I / O调用在TCP堆栈缓冲区和用户缓冲区之间保存了一个缓冲区副本。” （3）