Wiki: Current state of the art of Delphi 3rd party TCP/IP components libraries

Question

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.

Answer 1

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:

• ships with Delphi
• mature
• development community
• open source so lots of eyes scrutinizing those sources
• a truckload of valuable comment documentation in the source code
• OpenSSL support
• supports a broad set of Delphi versions (including 2007 and XE)
• wide choice of protocols

Con:

• the version shipping with Delphi was not always the most stable one; download from the sources was usually required to get a stable build
• (in the mean time) lots of duplication of code that now is in Delphi (but Indy requires for compatibility with older Delphi versions)
• not all TCP/IP components were up-to-date (for instance, back then the POP3 client component did not support some basic POP3 commands)
• version interoperability was a pain: upgrading from one Indy version to another could be very time consuming
• I'm ambivalent on the exception handling and anti-freeze in Indy, though I got used to it, it still felt somewhat unnatural.
• breaking changes are made between build updates; ifdefs required to accommodate those
• Unclear release status if any at all, no RCs for a long while, getting trunk can make your local copy unstable

Answer 2

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:

• Works asynchronously
• Somewhat easier on beginners because it doesn't need threads
• Supports a good number of protocols

Cons:

• Relies on Windows messaging. I'm simply not comfortable with that.
• The async behavior makes implementing most protocols slightly difficult (because most protocols are in the form of send command / receive response). This shouldn't matter for most people since ICS offers ready-made implementation for the most-used protocols.

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!