Zwei Bibliotheken, zwei verschiedene Aufgaben
Fast jeder Delphi-Entwickler hat irgendwann Indy verwendet. Es liegt der IDE bei, gibt es seit Ende der 1990er-Jahre und eine Generation Delphi-Netzwerkcode baut auf TIdHTTP, TIdTCPClient, TIdSMTP und Co. auf. sgcWebSockets ist eine viel jüngere kommerzielle Bibliothek, die sich auf die Protokolle konzentriert, die erst nach Indys ursprünglichem Entwurf aufgetaucht sind — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — plus einen großen Katalog von REST-API-Integrationen.
Die häufigste Frage in den Embarcadero-Foren und auf Stack Overflow ist eine Variante von „Warum sollte ich für sgcWebSockets bezahlen, wenn Indy kostenlos ist?“. Die kurze Antwort lautet: Sie lösen unterschiedliche Probleme, und in vielen realen Projekten wirst du beide nutzen. Dieser Artikel geht die praktischen Unterschiede 2026 durch, damit du entscheiden kannst, was (oder welche Kombination) zu deiner Anwendung passt.
Was jede Bibliothek tatsächlich tut
Indy ist ein universelles TCP-/UDP-Toolkit mit einer langen Liste klassischer Internet-Protokolle: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois plus ein TCP-Server-Framework. Sein Design ist Thread-pro-Verbindung mit blockierender I/O. Stock-Indy hat keinen nativen WebSocket-Client oder -Server — du musst einen aufsetzen, und mehrere Community-Projekte tun genau das mit gemischten Ergebnissen.
sgcWebSockets ist eine fokussierte, protokollreiche Bibliothek für moderne Client-/Server-Szenarien. Sie ist um ein Kernpaar TsgcWebSocketClient / TsgcWebSocketHTTPServer organisiert, mit optionalen Add-ons für HTTP/2, HTTP/3 über QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), Ende-zu-Ende-Verschlüsselung sowie über 30 API-Wrapper (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp usw.).
Ein wichtiges und oft übersehenes Detail: sgcWebSockets verwendet Indy intern als einen seiner Transport-Backends. Die TCP-/TLS-Plumbing-Schicht mehrerer Komponenten ist unter der Haube ein Indy-TIdTCPClient / TIdHTTPServer — sgcWebSockets zu installieren ersetzt Indy also nicht, sondern baut darauf auf. Die Bibliothek bietet zusätzlich alternative Transports (Synapse-artig, ICS, SChannel) für Szenarien, in denen Indy nicht ideal passt.
Feature-für-Feature-Vergleich
| Feature | Indy (stock) | sgcWebSockets |
|---|---|---|
| HTTP/1.1-Client | Ja (TIdHTTP) | Ja (TsgcHTTPComponentClient, kann Indy- oder ICS-Backend nutzen) |
| HTTP/1.1-Server | Ja (TIdHTTPServer) | Ja (TsgcWebSocketHTTPServer, behandelt HTTP + WS auf demselben Port) |
| WebSocket-Client/-Server | Keine native Unterstützung | Vollständiges RFC 6455, permessage-deflate, Subprotokolle, Autobahn-getestet |
| HTTP/2 (h2 + h2c) | Nein | Ja, eigene HPACK- + Frame-Schicht |
| HTTP/3 / QUIC | Nein | Ja (msquic-basiert) |
| MQTT 3.1.1 und 5.0 | Nein | Ja, Client und Broker |
| AMQP 1.0 / 0.9.1 | Nein | Ja |
| STOMP, SSE, WAMP | Nein | Ja |
| WebRTC / P2P / STUN / TURN | Nein | Ja |
| CoAP und IoT-Cloud (AWS, Azure) | Nein | Ja |
| OpenAI, Anthropic, Gemini, MCP | Nein | Ja, dedizierte Komponenten |
| FTP / SMTP / POP3 / IMAP | Ja | Nein (dafür Indy nutzen) |
| Kostenlos / kommerziell | Kostenlos, MIT-artig | Kommerziell, mehrere Editionen inkl. Free |
| Delphi-Versionen | D7 und höher (variiert je Fork) | D7 bis D13 |
| Aktive Pflege | Community (IndyProject auf GitHub) | Hersteller, monatliche Releases |
Wo Indy weiterhin gewinnt
Wenn dein Projekt ein klassischer Internet-Client ist — eine Datei über HTTP herunterladen, ein Formular posten, eine SMTP-E-Mail senden, Mail über IMAP holen, mit einem alten FTP-Server reden — ist Stock-Indy die richtige Antwort. Es ist kostenlos, der IDE beigelegt, die API ist vertraut, und mehr brauchst du nicht. Dasselbe gilt für Hobby-TCP-Server und Protokolle, die Indy nativ liefert (NNTP, IRC, Telnet, Whois). Für diese Anwendungsfälle ist eine bezahlte Bibliothek Overkill.
Indy ist auch die naheliegende Wahl, wenn du mit Code zusammenarbeiten musst, der bereits Indy-Typen verwendet — etwa Komponenten, die einen TIdSSLIOHandlerSocketOpenSSL oder einen TIdHTTPServerCommandHandler erwarten.
Wo sgcWebSockets das richtige Werkzeug ist
Alles rund um den modernen Web-Stack ist mit sgcWebSockets deutlich einfacher. Konkret:
- WebSocket — voll-duplexes Messaging ist erstklassige Funktion. Der Server bedient HTTP und WebSocket auf demselben Port, verwaltet Subprotokolle, unterstützt Kompression und ist mit dem Auto-Reconnect-WatchDog out of the box integriert.
- HTTP/2 und HTTP/3 — nötig für Apple Push Notifications, Google-Dienste und eine wachsende Zahl von REST-APIs, die mindestens h2 erzwingen. Indy hat hier keine Antwort.
- Messaging-Broker — MQTT 5, AMQP 1.0, STOMP, WAMP und SSE liegen als gebrauchsfertige Komponenten mit TLS, Reconnect und Authentifizierung bei.
- Echtzeit-Multimedia — WebRTC, ICE, STUN, TURN und DTLS-SRTP für browserkompatible Audio-/Video- und Data-Channels.
- KI- und Cloud-APIs — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe und ein paar Dutzend weitere sind als typisierte Komponenten gewrappt statt als rohe REST-Aufrufe.
Performance und Skalierung
Das Thread-pro-Verbindung-Modell von Indy ist einfach und korrekt, deckelt aber den praktischen Durchsatz auf einem typischen Windows-Server bei wenigen Tausend gleichzeitigen Verbindungen, bevor Context-Switching zum Flaschenhals wird. sgcWebSockets bietet aus Kompatibilitätsgründen denselben Indy-Backend, plus einen IOCP-basierten Server-Transport unter Windows, der bei Zehntausenden gleichzeitiger WebSocket-Verbindungen pro Prozess gemessen wurde. Bei reinem HTTP-Durchsatz ist der Unterschied kleiner, aber für langlebige Verbindungen (WebSocket, MQTT, SSE) macht die Architekturlücke einen Unterschied.
Auch der Speicher-Fußabdruck pro Idle-Verbindung ist mit dem IOCP-Transport geringer, weil kein dedizierter OS-Thread pro Socket nötig ist. Unter Linux sieht es ähnlich aus mit den epoll-basierten Servern aus dem von sgcWebSockets ausgelieferten Indy-Fork.
Pflege und Release-Kadenz
Indy wird von einer kleinen Gruppe Freiwilliger im IndyProject-GitHub-Repository gepflegt. Releases kommen langsam, die Codebasis ist aber stabil. Kritische Fixes (TLS-Kompatibilität, moderne OpenSSL-Bindings) landen, aber nicht immer schnell.
sgcWebSockets ist ein kommerzielles Produkt von eSeGeCe mit monatlichen Releases, einer öffentlichen History-Datei und direktem Hersteller-Support. Neue Delphi-Versionen werden typischerweise am Tag 1 unterstützt — Delphi 13 ab der ersten Beta — und neue Protokollrevisionen (MQTT 5.0.1, HTTP/3-final, MCP-Spezifikations-Updates) erscheinen in Tagen statt Jahren.
Lizenz und Preise
Indy ist kostenlos und liegt Delphi bei. sgcWebSockets ist kommerziell, hat aber eine Free Edition für nicht-kommerzielle Nutzung sowie kostenpflichtige Editionen (Standard, Professional, Enterprise, All-Access) mit zunehmend breiterer Protokollabdeckung. Die meisten kommerziellen Projekte können eine Single-Developer-Professional-Lizenz mit einem einzigen ausgelieferten Kunden rechtfertigen.
Eine einfache Entscheidungsregel
Eine pragmatische Daumenregel für 2026:
- Nutze Indy für SMTP/POP3/IMAP/FTP, für kurzlebige HTTP-Downloads in einer bestehenden Indy-Codebasis oder für jedes klassische Internet-Protokoll, das Indy bereits nativ behandelt.
- Nutze sgcWebSockets, sobald WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT oder eine KI-/REST-API ins Spiel kommt — oder wenn du einen Server brauchst, der über ein paar Tausend Verbindungen hinaus skaliert.
- Nutze beide im selben Projekt — das ist tatsächlich das häufigste Muster. Indy bleibt für die E-Mail- und FTP-Schicht, sgcWebSockets handhabt die Echtzeit- und Modern-API-Schicht, und sie teilen sich die gleiche Indy-SSL/IO-Infrastruktur darunter.
Abschluss
Indy geht nirgendwo hin — es ist der zuverlässige Hammer in jeder Delphi-Werkzeugkiste. Aber die Protokolle, die das Internet 2026 definieren (WebSocket, HTTP/2/3, MQTT, WebRTC, KI-APIs), existierten schlicht nicht, als Indy entworfen wurde. sgcWebSockets füllt diese Lücke mit einer fokussierten, aktiv gepflegten, kommerziell unterstützten Bibliothek, die auf Indy aufbaut, wo es nützlich ist, und es ersetzt, wo nötig. Für neue Projekte mit modernen Backends lautet die Frage nicht mehr Indy oder sgcWebSockets? — sondern wie kombiniere ich sie?