Wiki：Delphi 第 3 方 TCP/IP 组件库的最新技术
我已经大约 18 个月没有做裸机 TCP/IP 了，所以我想知道当前的技术水平如何。
我正在寻找服务器和客户端软件开发的积极和消极方面。
我将做一个需要坚如磐石的 TCP/IP 层的项目，所以对我来说这是一个重要的方面:)
为了使其成为一个社区 wiki，我正在寻找更广泛的答案，而不仅仅是“坚如磐石”。因此，例如有关特征宽度的信息也是值得赞赏的。
我将使用答案中找到的相关方面来更新问题，以便获得对这些库有平衡概述的 wiki 条目。
例如，请参阅下面我的回答以及我过去在印地的经历 我对 Indy 中的异常处理和防冻结持矛盾态度，虽然已经习惯了，但还是感觉有些不自然。
现在我使用 Delphi 2007（非 Unicode）和 XE（Unicode）进行开发，因此我正在考虑的库应该至少支持这两个 Delphi 版本。
I've not been doing bare metal TCP/IP for about 18 months, so I wonder what the current state of the art is.
I'm looking for both positive and negative aspects, with development of both server and client software.
I will be doing a project that needs a rock-solid TCP/IP layer, so for me that is an important aspect :)
For this to become a community wiki, I'm looking for broader answers than just 'rock solid'. So for instance information about the feature-width is also appreciated.
I'll be updating the question with relevant aspects found in the answers in order to get a wiki entry that has a balanced overview of those libraries.
For example, see my answer below with my past experience with Indy
I'm ambivalent on the exception handling and anti-freeze in Indy, though I got used to it, it still felt somewhat unnatural.
Right now I develop in both Delphi 2007 (non Unicode) and XE (Unicode), so the libraries I'm considering should support at least those two Delphi versions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
编辑：我过去使用 Indy 的经验总结以及评论（感谢 Eugene< /a>, Marjan)
（请更新当前 Indy 的最新技术）：
Pro：
缺点：
Edit: Summary of my past experience with Indy, and the comments (thanks Eugene, Marjan)
(please update with the current Indy state of the art):
Pro:
Con:
ICS - 互联网组件套件
ICS - 请参阅 www.overbyte.be。由 François Piette 开源。对我来说，这一直是印地的第一选择。这是最有趣的卖点：它使使用异步东西变得容易，并且异步似乎更接近“裸机”套接字编程。
我用它构建了一个相当复杂的 VNC 代理，其中代理本身（服务器）是使用 ICS 构建的，而客户端是 Indy 和 ICS 的混合体。在高需求时期，代理可以处理大约 100 个同时连接和大约 10 个同步 VNC 屏幕会话。它平均消耗 5 Mbit/s，处理两个不同互联网连接上的连接。我不认为 100 + 10 是极限，因为服务器处理这个问题没有任何问题，而且 CPU 使用率太低了。
优点：
缺点：
话虽这么说，我已经很长时间没有使用 ICS 了，我不太了解所有的花哨功能。这是CW，所以请编辑和扩展！
ICS - The Internet Component Suite
ICS - see www.overbyte.be. Open source by François Piette. To me this has always been the number 1 alternative to Indy. It's most interesting selling point: it makes using asynchronous stuff easy, and being async seems to be closer to "bare metal" sockets programming.
I've used it to build a fairly complex VNC proxy where the proxy itself (server) is built with ICS and the clients are a mixture of Indy and ICS. In periods of high demand the proxy handles about 100 simultaneous connections and about 10 simultaneous VNC screen sessions. It eats up an average of 5 mbit/s, handles connections over two distinct Internet connections. I don't think the 100 + 10 is the limit, because the server handles that without any problems and CPU usage is too low to mention.
Pros:
Cons:
All that being said, I haven't used ICS in a very long time, I'm not up-to-date with all the bells and whistles. This is CW, so please edit and expand!
我自 2003 年起就使用 Indy 作为我自己的 TCP 通信框架。它坚如磐石，我有一个与 Delphi 2007 一起使用的版本，另一个与 Delphi 2010 一起使用的版本，如果正确处理线程，则无需使用防冻东西，并且我在客户端和服务器上具有一致的异常处理通过实现我自己的包装器来解决这个问题。
您可以在此处下载 (http://www.csinnovations.com/framework_delphi.htm) -查找Tcp单元，主要是AppTcpServerUnt和AppTcpClientUnt。
I have used Indy since 2003 for my own TCP communications framework. It is rock-solid, I have a version used with Delphi 2007 and another with Delphi 2010, if you handle the threadng correctly there is no need to use the anti-freeze stuff, and I have consistent exception handling on the client and the server by implementing my own wrapper around this.
You can dowload it here (http://www.csinnovations.com/framework_delphi.htm) - look for the Tcp units, mainly AppTcpServerUnt and AppTcpClientUnt.
我强烈推荐 Clever Internet Suite，它是迄今为止设计和编写得最好的通信组件集。它不是免费的，因此不太出名，但非常值得研究。
优点：
Con：
I would strongly recommend Clever Internet Suite, it's by far the best designed and written set of communication components. It's not free and so not that well known, but it's well worth investigating.
Pro:
Con:
您可以考虑使用更高级别的协议，例如 HTTP，因为：
在这种情况下，您可以查看来自 Delphi 的两个开源类 6 至 XE：
THttpApiServer，它使用快速 http.sys 内核模式服务器实现 HTTP 服务器：使用 Microsoft Internet 信息服务器 (IIS)。应用程序可以注册
接收特定 URL 的 HTTP 请求、接收 HTTP 请求并发送
HTTP 响应。 HTTP 服务器 API 包括 SSL 支持，以便应用程序
无需 IIS，即可通过安全 HTTP 连接交换数据。这也是
设计用于与 I/O 完成端口配合使用。
以及带有 Service Pack 2 (SP2) 的 Windows XP。请注意，Microsoft IIS 5
在带有 SP2 的 Windows XP 上运行无法与其他 HTTP 共享端口 80
同时运行的应用程序。
TWinHTTP使用 WinHTTP API 处理客户端 HTTP/1.1 请求：需要访问 HTTP 客户端堆栈的后端服务器应用程序；
WinINetAPI 快得多。由此产生的速度非常好（尤其是服务器），并且您将依赖于 Microsoft 的实现。第一个是 IIS 的核心，第二个用于最新版本的 Internet Explorer。
You could consider using a higher protocol level like HTTP, because:
In this case, you could take a look at two Open Source classes working from Delphi 6 up to XE:
THttpApiServerwhich implements a HTTP server using fast http.sys kernel-mode server:using Microsoft Internet Information Server (IIS). Applications can register
to receive HTTP requests for particular URLs, receive HTTP requests, and send
HTTP responses. The HTTP Server API includes SSL support so that applications
can exchange data over secure HTTP connections without IIS. It is also
designed to work with I/O completion ports.
and on Windows XP with Service Pack 2 (SP2). Be aware that Microsoft IIS 5
running on Windows XP with SP2 is not able to share port 80 with other HTTP
applications running simultaneously.
TWinHTTPwhich handles client-side HTTP/1.1 request using the WinHTTP API:back-end server applications that require access to an HTTP client stack;
WinINetAPI.Resulting speed is very good (especially the server), and you will rely on Microsoft implementation. The first is the core of IIS, and the second is used in the latest versions of Internet Explorer.
答案实际上取决于许多因素和您的要求，例如
一般来说，18 个月甚至 3 年内并没有发生太多（积极的）事情，因为大多数开发人员将 .NET 视为主要开发平台。
其他答案中提到的 Clever Internet Suite 和 DevArt 的 SecureBridge 获得了一些新功能。
我们的 SecureBlackbox 提供对最高级功能（除了本机 SSL/TLS 之外）的支持：IPv6、HTTPS 代理基本、摘要和 NTLM 身份验证（从 SecureBlackbox 9 开始）、国际域名（从 SecureBlackbox 9 开始）、DNSSEC、带宽控制等。
SecureBlackbox 支持的应用程序级协议有 HTTP（客户端和服务器）、WebDAV（客户端和服务器）、FTP（客户端和服务器）、SSH 和 SFTP（客户端和服务器）、SMTP 和 POP3 客户端、DNS 客户端、AS2 和 AS3。所有协议（当然除了 SSH 和 SFTP）都完全支持 SSL/TLS。
支持的协议列表可以在软件包页面上找到。每个包的技术规格页面上列出了支持的协议功能。
The answer really depends on many factors and your requirements, such as
In general, not much (positive) happened in 18 months or even in 3 years as most developers look at .NET as primary development platform.
Clever Internet Suite mentioned in other answer and DevArt's SecureBridge gained some new functionality.
Our SecureBlackbox offers support for the most advanced features (besides native SSL/TLS): IPv6, HTTPS Proxy with basic, digest and NTLM authentication (starting with SecureBlackbox 9), International Domain Names (starting with SecureBlackbox 9), DNSSEC, bandwidth control and more.
Application-level protocols supported by SecureBlackbox are HTTP (client and server), WebDAV (client and server), FTP (client and server), SSH and SFTP (client and server), SMTP and POP3 clients, DNS client, AS2 and AS3. All of the protocols (besides SSH and SFTP, of course) have complete support for SSL/TLS.
The list of supported protocols can be found on Packages page. Supported protocol features are listed on Technical Specification page for each package.
在旧的 Delphi 版本（2！3！4！）中以 NetMaster 组件的方式（方式！）
与 Indy 一起工作，但也有不自然的感觉（实际上我更愿意将其描述为笨重）
偶然发现 Synapse 当我正在寻找围绕 Windows 网络 API 的轻量级包装器时，
然后重新发现普通的旧 TTcpClient/TTcpServer。它们是 Delphi 自己的winsock 包装器！我使用它们来阻塞，每个 TTcpClient 都有一个专用的 TThread 继承，并让 TTcpServer 执行线程并完成 DoAccept 中的所有工作，请参阅 此处 为例。
现在，这给了我我们正在寻找的坚如磐石的感觉。如果您想支持重负载，我会尝试构建一个线程管理器，它可以处理每个线程的多个套接字/连接，或者有两组线程：一组监听大量的“休眠”连接，另一组则处理较少的“活动”连接，根据是否正在处理请求或响应来切换线程之间的连接。 （例如 HTTP 的
Connection: keep-alive）Worked with NetMaster components way (way!) back in the old Delphi versions (2! 3! 4!)
Did some work with Indy, but had the unnatural feeling also (actually I'd describe it more as bulky)
Stumbled upon Synapse when I was searching for just a light wrapper around the Windows network API,
And then rediscovered plain old TTcpClient/TTcpServer. They are Delphi's own wrapper around winsock! I use them blocking, with a dedicated TThread inheritant for each TTcpClient, and let TTcpServer do the threads and do all the work in DoAccept, see here for an example.
This, fow now, gave me the rock-solid feel we're looking for. If you want to support heavy load, I would try and build a thread manager that handles several sockets/connections per thread, or have two sets of threads: a few that listen a larger number of 'dormant' connections, and the others that handle lesser 'active' connections, switching connections between the threads depending on wether a request or response is being handled. (e.g. HTTP's
Connection: keep-alive)