The other long-standing Delphi networking library
For Delphi developers shopping for a networking library in 2026, three names tend to come up: Indy, Overbyte ICS (Internet Component Suite by François Piette), and sgcWebSockets. ICS has been around almost as long as Indy and has a devoted following, especially among developers who appreciate its non-blocking, message-pump-based architecture. sgcWebSockets is the newer commercial library focused on modern protocols.
This article compares the two head-to-head: feature coverage, WebSocket support, HTTP/2 and HTTP/3, license, developer experience, and commercial support. Where the comparison depends on a specific ICS release, claims are based on the publicly documented v9 series as of writing — check the current ICS changelog if you need an exact feature confirmation.
Origins and design philosophy
ICS started life in the 1990s as a set of asynchronous, event-driven WinSock wrappers. The classic ICS components (TWSocket, THttpCli, TSslHttpServer) use a non-blocking message-pump model: every socket operation posts a Windows message and you respond in an event handler. That model fits the Delphi VCL beautifully — no threads, no synchronisation primitives, runs on the main thread. ICS later added a thread-pooled HTTP server (TSslHttpAppSrv) for higher concurrency.
sgcWebSockets was designed around a different problem: long-lived bidirectional connections (WebSocket, MQTT, SSE, gRPC-style streams) and modern transport stacks (HTTP/2, HTTP/3 over QUIC). It uses an IOCP-based server on Windows for scaling and an event-driven client model for low-latency messaging. It also wraps Indy and ICS as alternative HTTP backends, so you can pick the transport that fits your environment.
Feature-by-feature comparison
| Feature | Overbyte ICS (v9, as of writing) | sgcWebSockets |
|---|---|---|
| HTTP/1.1 client | Yes (THttpCli, TSslHttpCli) | Yes, multiple backends |
| HTTP/1.1 server | Yes (TSslHttpAppSrv) | Yes |
| WebSocket client | Yes (since v8) | Yes, full RFC 6455 |
| WebSocket server | Yes (since v8) | Yes, sub-protocols, per-message deflate, channels |
| HTTP/2 | Limited / not a first-class feature | Yes, full HPACK + frame layer |
| HTTP/3 / QUIC | No | Yes (msquic-based) |
| MQTT 3.1.1 / 5.0 | No native broker, basic client only | Full client + broker, both versions |
| AMQP 1.0 / 0.9.1 | No | Yes |
| STOMP, SSE, WAMP | SSE basic, others no | All supported |
| WebRTC / STUN / TURN / DTLS-SRTP | No | Yes |
| CoAP, AWS IoT, Azure IoT | No | Yes |
| SMTP / POP3 / IMAP / FTP / NNTP | Yes, mature implementations | No (use Indy or ICS) |
| OpenSSL bindings | Yes, very up-to-date | Yes, plus SChannel and BoringSSL |
| 30+ REST API wrappers (OpenAI, Anthropic, AWS, Azure, exchanges) | No | Yes |
| License | Free, mozilla-style | Commercial, Free Edition available |
| Delphi versions | D7 through D13 | D7 through D13 |
| Maintenance | Active, vendor-led (Magenta Systems) | Active, vendor-led, monthly releases |
| Commercial support | Optional paid support contracts | Included with paid editions |
WebSocket support
ICS added WebSocket components in v8 (TIcsWebSocketClient, server-side via TSslHttpAppSrv with WebSocket handlers). They cover RFC 6455 and TLS, which is enough for many use cases. What ICS does not yet provide out of the box is per-message deflate by default, named channels / broadcast groups, an auto-reconnect WatchDog, JavaScript client glue, or built-in protocols on top of WebSocket (WebSocket-MQTT, WebSocket-STOMP, WAMP).
sgcWebSockets treats WebSocket as the centre of the universe. The server multiplexes HTTP and WebSocket on the same port, ships with channels and broadcast helpers, includes a JavaScript client that mirrors the Delphi API, and adds WatchDog auto-reconnect, heartbeat ping/pong, message queues, and an LB-style load balancer component. If you live and breathe WebSocket, the developer experience is noticeably richer.
HTTP/2 and HTTP/3
This is the area with the biggest gap. As of writing, ICS does not list HTTP/2 as a first-class feature in the v9 release notes — some experimental work has been discussed on the public mailing list but the recommended path for HTTP/2 inside an ICS application is to use a separate library.
sgcWebSockets has shipped a full HTTP/2 implementation since 2018, including the HPACK header compression algorithm, frame multiplexing, server push, and ALPN negotiation. The same code path is used by the Apple Push Notification client, the Google FCM client, and any HTTP/2 server endpoint you build. HTTP/3 over QUIC was added in 2023 using Microsoft's msquic library on Windows and ngtcp2 on Linux. For applications that need bleeding-edge transport support, this is a meaningful differentiator.
Classic Internet protocols
ICS wins clearly here. SMTP, POP3, IMAP, FTP, NNTP, DNS and even an HTTP proxy server are all included and well maintained. If you are building an email client, an FTP front-end or an SMTP relay, ICS is a stronger starting point than sgcWebSockets (which does not ship those protocols at all).
A common combination is to use ICS for the mail/FTP layer and sgcWebSockets for the WebSocket / HTTP/2 / MQTT layer in the same product. Both libraries coexist happily because they have separate unit namespaces.
SSL / TLS
Both libraries take TLS seriously. ICS is well known for tracking new OpenSSL releases extremely quickly — new OpenSSL 3.x minor versions are usually supported within days. sgcWebSockets also tracks OpenSSL and additionally supports Windows SChannel and BoringSSL, plus its own end-to-end encryption layer for application-level confidentiality on top of TLS.
Developer experience
ICS uses an event-driven, message-pump style API that is very natural inside a VCL form — you drop a component, wire up OnDataAvailable or OnRequestDone, and Windows messages drive the flow. It is light on threads, easy to debug, and idiomatic for classic VCL development. The downside is that scaling beyond a single message pump requires either the thread-pooled server variants or explicit multi-instance designs.
sgcWebSockets follows the more recent component convention used by Indy and modern REST libraries: a component with strongly typed options sub-objects (HeartBeat, WatchDog, TLSOptions, etc.), event-driven callbacks, and worker threads under the hood. The IOCP server transport scales to tens of thousands of concurrent connections without user code changes.
License and pricing
ICS is free for both commercial and non-commercial use under a Mozilla-style license. Optional commercial support contracts are available from Magenta Systems. sgcWebSockets is commercial, with a Free Edition for non-commercial use and four paid editions (Standard, Professional, Enterprise, All-Access). Paid editions include source code, monthly updates, and direct vendor support.
Decision matrix
| If you need… | Best choice |
|---|---|
| SMTP, POP3, IMAP, FTP, NNTP clients | ICS |
| Tiny single-form HTTP fetcher with no threading | ICS |
| Bleeding-edge OpenSSL tracking | ICS (sgc is very close) |
| WebSocket client/server with channels, WatchDog, JS client | sgcWebSockets |
| HTTP/2 client or server, Apple Push, FCM | sgcWebSockets |
| HTTP/3 / QUIC | sgcWebSockets |
| MQTT 5 broker, AMQP 1.0, WAMP, STOMP | sgcWebSockets |
| WebRTC, STUN, TURN, IoT, CoAP | sgcWebSockets |
| Ready-made OpenAI / Anthropic / cloud API components | sgcWebSockets |
| Commercial vendor support contract | Either — sgcWebSockets bundled, ICS optional |
Closing thoughts
ICS and sgcWebSockets are not really competitors so much as complementary tools. ICS is a beautifully engineered, free, message-pump-friendly library that excels at classic Internet protocols and lightweight HTTP. sgcWebSockets is a focused commercial library that owns the modern web stack — WebSocket, HTTP/2/3, MQTT, AMQP, WebRTC, IoT, AI APIs — and scales to large numbers of concurrent connections. The right answer for many real projects is to use both, picking each library for the protocols it does best.