Twee bibliotheken, twee verschillende taken
Bijna elke Delphi-ontwikkelaar heeft op enig moment Indy gebruikt. Het zit standaard in de IDE, bestaat al sinds eind jaren negentig, en een generatie Delphi-netwerkcode is gebouwd op TIdHTTP, TIdTCPClient, TIdSMTP en consorten. sgcWebSockets is een veel nieuwere commerciele bibliotheek die zich richt op de protocollen die zijn ontstaan sinds Indy oorspronkelijk werd ontworpen — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — plus een grote catalogus REST-API-integraties.
De meest gestelde vraag op de Embarcadero-forums en Stack Overflow is een variant van “Waarom zou ik voor sgcWebSockets betalen als Indy gratis is?”. Het korte antwoord is dat ze verschillende problemen oplossen, en in veel echte projecten gebruik je uiteindelijk allebei. Dit artikel doorloopt de praktische verschillen in 2026 zodat je kunt beslissen welke (of welke combinatie) bij je toepassing past.
Wat elke bibliotheek werkelijk doet
Indy is een algemene TCP/UDP-toolkit met een lange lijst klassieke internetprotocollen: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, plus een TCP-server-framework. Het ontwerp is thread-per-verbinding en blokkerende I/O. Er is geen native WebSocket-client of -server in de standaard Indy — je moet er een aan vastschroeven, en verschillende community-projecten doen precies dat met wisselend resultaat.
sgcWebSockets is een gerichte, protocolrijke bibliotheek gericht op moderne client/server-scenario’s. Het is georganiseerd rondom een kern-TsgcWebSocketClient/TsgcWebSocketHTTPServer-paar met optionele uitbreidingen voor HTTP/2, HTTP/3 over QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), end-to-end-encryptie en 30+ API-wrappers (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp, etc.).
Een belangrijk en vaak gemist detail: sgcWebSockets gebruikt Indy intern als een van de transport-backends. De TCP/TLS-bedrading voor verschillende componenten is onder de motorkap een Indy TIdTCPClient/TIdHTTPServer, dus het installeren van sgcWebSockets vervangt Indy niet — het bouwt erbovenop. De bibliotheek biedt ook alternatieve transporten (Synapse-style, ICS, SChannel) voor scenario’s waarin Indy niet de beste keus is.
Feature-vergelijking
| Feature | Indy (standaard) | sgcWebSockets |
|---|---|---|
| HTTP/1.1-client | Ja (TIdHTTP) | Ja (TsgcHTTPComponentClient, kan Indy- of ICS-backend gebruiken) |
| HTTP/1.1-server | Ja (TIdHTTPServer) | Ja (TsgcWebSocketHTTPServer, verwerkt HTTP + WS op dezelfde poort) |
| WebSocket-client/server | Geen native ondersteuning | Volledige RFC 6455, permessage-deflate, subprotocollen, autobahn-getest |
| HTTP/2 (h2 + h2c) | Nee | Ja, eigen HPACK + frame-laag |
| HTTP/3 / QUIC | Nee | Ja (msquic-gebaseerd) |
| MQTT 3.1.1 en 5.0 | Nee | Ja, client en broker |
| AMQP 1.0 / 0.9.1 | Nee | Ja |
| STOMP, SSE, WAMP | Nee | Ja |
| WebRTC / P2P / STUN / TURN | Nee | Ja |
| CoAP en IoT-cloud (AWS, Azure) | Nee | Ja |
| OpenAI, Anthropic, Gemini, MCP | Nee | Ja, speciale componenten |
| FTP / SMTP / POP3 / IMAP | Ja | Nee (gebruik daarvoor Indy) |
| Gratis / commercieel | Gratis, MIT-stijl | Commercieel, meerdere edities incl. Free |
| Delphi-versies | D7 en hoger (verschilt per fork) | D7 t/m D13 |
| Actief onderhoud | Community (IndyProject op GitHub) | Leverancier, maandelijkse releases |
Waar Indy nog steeds wint
Als je project een klassieke internetclient is — een bestand downloaden over HTTP, een formulier posten, een SMTP-e-mail versturen, mail ophalen via IMAP, met een oude FTP-server praten — dan is de standaard Indy het juiste antwoord. Het is gratis, het zit bij de IDE, de API is vertrouwd, en je hebt verder niets nodig. Hetzelfde geldt voor hobby-TCP-servers en protocollen die Indy native meelevert (NNTP, IRC, Telnet, Whois). Voor zulke use cases is het toevoegen van een betaalde bibliotheek overkill.
Indy is ook de voor de hand liggende keuze wanneer je moet samenwerken met code die al Indy-types gebruikt — bijvoorbeeld componenten die een TIdSSLIOHandlerSocketOpenSSL of een TIdHTTPServerCommandHandler verwachten.
Waar sgcWebSockets de juiste tool is
Alles wat met de moderne webstack te maken heeft, is aanzienlijk makkelijker met sgcWebSockets. Concreet:
- WebSocket — full-duplex messaging is een first-class feature. De server verwerkt HTTP en WebSocket op dezelfde poort, beheert subprotocollen, ondersteunt compressie, en integreert out-of-the-box met de auto-reconnect WatchDog.
- HTTP/2 en HTTP/3 — vereist voor Apple Push Notifications, Google-diensten, en een groeiend aantal REST-API’s die zijn begonnen met het afdwingen van minimum h2. Indy heeft hier geen antwoord op.
- Messaging-brokers — MQTT 5, AMQP 1.0, STOMP, WAMP en SSE worden allemaal geleverd als kant-en-klare componenten met TLS, reconnectie en authenticatie.
- Realtime multimedia — WebRTC, ICE, STUN, TURN en DTLS-SRTP voor browser-compatibele audio/video en datakanalen.
- AI- en cloud-API’s — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe en enkele tientallen andere worden verpakt als getypeerde componenten in plaats van ruwe REST-aanroepen.
Prestaties en schaling
Het thread-per-verbinding-model van Indy is simpel en correct, maar het beperkt de praktische doorvoer tot enkele duizenden gelijktijdige verbindingen op een typische Windows-server voordat context-switching de bottleneck wordt. sgcWebSockets biedt voor compatibiliteit dezelfde Indy-backend, plus een IOCP-gebaseerd server-transport op Windows dat in benchmarks tientallen duizenden gelijktijdige WebSocket-verbindingen per proces heeft gehaald. Voor pure HTTP-doorvoer is het verschil kleiner, maar voor langlevende verbindingen (WebSocket, MQTT, SSE) telt het architecturele verschil mee.
De geheugen-footprint per inactieve verbinding is met het IOCP-transport ook lager omdat er geen toegewijde OS-thread per socket is. Op Linux is het beeld vergelijkbaar met epoll-gebaseerde servers via de Indy-fork die sgcWebSockets meelevert.
Onderhoud en releasefrequentie
Indy wordt onderhouden door een kleine groep vrijwilligers op de IndyProject-GitHub-repository. Releases zijn traag maar de codebase is stabiel. Kritieke fixes (TLS-compatibiliteit, moderne OpenSSL-bindingen) komen er wel, maar niet altijd snel.
sgcWebSockets is een commercieel product van eSeGeCe met maandelijkse releases, een publieke history-file, en directe leveranciersondersteuning. Nieuwe Delphi-versies worden meestal vanaf dag een ondersteund — Delphi 13 werd vanaf de eerste beta ondersteund — en nieuwe protocolversies (MQTT 5.0.1, HTTP/3-final, MCP-spec-updates) worden in dagen geleverd in plaats van jaren.
Licentie en prijzen
Indy is gratis en wordt meegeleverd met Delphi. sgcWebSockets is commercieel maar heeft een Free Edition voor niet-commercieel gebruik, plus betaalde edities (Standard, Professional, Enterprise, All-Access) met geleidelijk bredere protocoldekking. De meeste commerciele projecten kunnen een licentie voor een enkele ontwikkelaar Professional met een enkele geimplementeerde klant rechtvaardigen.
Een simpele beslissingsregel
Een pragmatische vuistregel voor 2026:
- Gebruik Indy voor SMTP/POP3/IMAP/FTP, voor kortlevende HTTP-downloads binnen een bestaande Indy-codebase, of voor elk klassiek internetprotocol dat Indy al native afhandelt.
- Gebruik sgcWebSockets zodra WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT of een AI/REST-API in beeld komt, of wanneer je een server nodig hebt die schaalt boven enkele duizenden verbindingen.
- Gebruik beide in hetzelfde project — dat is in feite het meest voorkomende patroon. Indy blijft voor de e-mail- en FTP-laag, sgcWebSockets verzorgt de realtime- en moderne-API-laag, en ze delen dezelfde Indy SSL/IO-infrastructuur eronder.
Afsluitende gedachten
Indy gaat nergens heen — het is de vertrouwde hamer in elke Delphi-gereedschapskist. Maar de protocollen die het 2026-internet definieren (WebSocket, HTTP/2/3, MQTT, WebRTC, AI-API’s) bestonden simpelweg niet toen Indy werd ontworpen. sgcWebSockets vult dat gat met een gerichte, actief onderhouden, commercieel ondersteunde bibliotheek die voortbouwt op Indy waar nuttig en het vervangt waar nodig. Voor nieuwe projecten gericht op moderne back-ends is de vraag niet langer Indy of sgcWebSockets? — het is hoe combineer ik ze?