问Indy还是ICS还是？

EN

我在很多项目中使用Indy。我主要使用9和10作为HTTP服务器和代理。这些项目有时会获得非常密集的流量(HTTP)。印第从来没有让我失望过。它的工作非常稳定。

但我也遇到了一些“奇怪”的情况，我必须深入挖掘才能找到潜在的问题。我也不喜欢Indy倾向于通过异常处理很多事情的方式。总的来说，我更喜欢ICS的编码风格。但让我去ICS吧。

ICS使用非阻塞套接字，而indy使用阻塞。虽然非阻塞是可以的，而且乍一看似乎更好，但我发现它在很多情况下都令人恼火。问题是，由于回调函数，代码的自然流丢失了。这使得编写过程化类型库变得更加困难。此外，我不喜欢通过消息处理所有事情的方式。对我来说，当它与多线程混合在一起时，它很快就会变得混乱。多线程是当今的主流。

因此，虽然我喜欢ICS的编码风格和代码质量，但我更喜欢Indy的简单使用和阻塞模式。您更喜欢什么取决于您，但这两个库都很成熟和稳定。

这是我的两点意见。

我也同时使用Indy和ICS。

大多数时候，我更喜欢Indy，因为使用它实现顺序类型的协议非常容易(请求在它自己的线程中运行，因此您只需对连接进行读/写操作，真的很容易)。使用Indy需要扎实的线程和同步知识。与Runner不同，我喜欢Indy使用异常处理“异常”的方式，因为它允许我专注于协议的正常流程(我使用try-finally块来确保释放资源)。

我还在Indy失败的应用程序中使用了ICS :我将其用于实现TCP/IP代理的应用程序。使用ICS更简单，因为它的非阻塞性质。我能够“代理”我不了解的TCP/IP协议，所以我不知道字节如何从一端流向另一端。Indy在这种情况下失败了，因为在Indy中，你正在以太阅读或正在写作，你不能同时做这两件事。使用ICS实现顺序类型的协议有点痛苦:您基本上需要使用状态机逻辑，在小块中停止协议，在周围放置标志以便知道您在协议中处于什么位置。一个很大的优点是: ICS的作者François Piette在许多论坛和邮件列表上都很活跃，非常乐于助人，并且非常迅速地帮助任何与ICS相关的事情。

对我来说，如果我需要使用TCP/IP做一些事情，决策路径非常简单:可以使用Indy来完成吗？那就是印地。如果它不能用Indy完成，那么可以用ICS完成！

我已经将Indy 9和10用于TCP、HTTP和FTP，几乎没有问题。ICS也是一个很好的选择。它是非阻塞的，这将改变你使用它的方式。

我还没有用过它，但我听说过Synapse的好消息，它也是阻塞的。