Indy或ICS还是？

Question

任何人都能告诉我哪个更稳定吗？我知道每个人都有自己的优点和缺点。但哪一个更适合http等？

在我之前的应用程序中，我使用了indy9，但我对它不满意，因为我有时会遇到奇怪的错误。

有人可以推荐吗？

Answer 1

我在许多项目中使用Indy。我主要使用9和10作为HTTP服务器和代理。项目有时会得到非常密集的流量（HTTP）。 Indy从来没有让我失望过。它非常稳定。

但我也有一些“奇怪”的情况，我不得不深挖以找到潜在的问题。我也不喜欢Indy倾向于通过异常处理很多事情的方式。总的来说，我更喜欢ICS编码风格。但是让我去ICS。

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

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

这是我的两分钱。

Answer 2

我也同时使用Indy和ICS。

大多数时候我更喜欢Indy，因为用它实现顺序类型的协议非常容易（请求在它自己的线程中运行，所以你只需要读/写连接，非常简单）。使用Indy需要扎实的线程和同步知识。与Runner不同，我喜欢Indy使用异常来处理“异常”的东西，因为它允许我专注于协议的正常流程（我使用try-finally块来确保我释放资源）。

我还在Indy完全失败的应用程序中使用了ICS：我将它用于实现TCP / IP代理的应用程序。使用ICS更简单，因为它具有非阻塞性。我能够“代理”我不了解的TCP / IP协议，所以我不知道字节将如何从一端流向另一端。 Indy在那种情况下失败了，因为在Indy你是以太读书或者你在写作，你不能同时做两件事。使用ICS实现顺序类型协议有点痛苦：您基本上需要使用状态机逻辑，以小位制动协议，保持标记，以便您知道协议中的位置。一个很大的优点：ICS的作者FrançoisPiette在许多论坛和邮件列表中非常活跃并且非常有帮助，并且非常及时地帮助处理与ICS相关的任何事情。

对我来说，如果我需要使用TCP / IP做一些事情，决策路径非常简单：可以用Indy完成吗？然后是Indy。如果无法用Indy完成，那么它将用ICS完成！

Answer 3

我已经将Indy 9和10用于TCP，HTTP和FTP，但问题很少。 ICS也是一个不错的选择。它是非阻塞的，会改变你使用它的方式。

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

Answer 4

我们测试Indy10 IdTCPClient从远程服务器接收视频流，没关系。但是当它接收流时，同时使用它向服务器发送一些数据，一段时间后，接收到的流数据开始丢失数据字节。我们使用sniffer工具来跟踪这个问题，确认IdTCPClient在接收流中丢失了一些字节。

所以，我们测试了Indy9.018，同样的问题发生了几次VS. Indy 10。

Answer 5

请记住，Indy始终处于测试阶段。有时您需要使用夜间构建。

Answer 6

哪一个更好取决于具体的用例，但我对indy作为一个http客户端感到不满意，而且ICS最终正是我需要的东西，而且随机怪癖的次数要少得多。

请注意，虽然它是非阻塞的，但它不仅仅是替代品。

Answer 7

我使用Indy 9为超过100万用户提供稳定，发布的生产代码，并且从未收到过任何奇怪的错误。

Answer 8

我会说答案取决于你想用互联网做什么。 Indy很好，如果你准备参与了解它是如何工作的，并且非常有能力。 ICS是一个不同的东西，我已经有效地将它用于多连接系统。但是对于日常“抓取文件或发送电子邮件”类型的东西，你想做基本任务，我几乎总是使用Clever Components Internet Suite来创建组件， 设置选项，它的工作原理。该套件非常全面，并且可以获得有用的更新。