Due librerie, due lavori diversi
Quasi ogni sviluppatore Delphi ha usato Indy a un certo punto. È distribuito nel box con l'IDE, è in giro dalla fine degli anni '90 e una generazione di codice di rete Delphi è costruita su TIdHTTP, TIdTCPClient, TIdSMTP e affini. sgcWebSockets è una libreria commerciale molto più recente, focalizzata sui protocolli apparsi da quando Indy è stato originariamente progettato — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — più un ampio catalogo di integrazioni REST API.
La domanda più comune sui forum Embarcadero e su Stack Overflow è qualche variazione di “Perché dovrei pagare per sgcWebSockets quando Indy è gratis?”. La risposta breve è che risolvono problemi diversi e in molti progetti reali finirai per usarli entrambi. Questo articolo passa in rassegna le differenze pratiche nel 2026 così puoi decidere quale (o quale combinazione) si adatta alla tua applicazione.
Cosa fa effettivamente ciascuna libreria
Indy è un toolkit TCP/UDP general-purpose con una lunga lista di protocolli Internet classici: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, più un framework di server TCP. Il suo design è thread-per-connessione e I/O bloccante. Non c'è alcun client o server WebSocket nativo in Indy stock — devi attaccarcelo, e diversi progetti della community fanno esattamente questo con risultati altalenanti.
sgcWebSockets è una libreria focalizzata e ricca di protocolli, mirata agli scenari client/server moderni. È organizzata attorno a una coppia core TsgcWebSocketClient / TsgcWebSocketHTTPServer con add-on opzionali per HTTP/2, HTTP/3 su QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), crittografia end-to-end e oltre 30 wrapper API (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp, ecc.).
Un dettaglio importante e spesso trascurato: sgcWebSockets usa Indy internamente come uno dei backend di trasporto. La parte TCP/TLS di diversi componenti è un TIdTCPClient / TIdHTTPServer di Indy sotto il cofano, quindi installare sgcWebSockets non sostituisce Indy — ci si costruisce sopra. La libreria offre anche trasporti alternativi (in stile Synapse, ICS, SChannel) per scenari in cui Indy non è la scelta migliore.
Confronto funzionalità per funzionalità
| Funzionalità | Indy (stock) | sgcWebSockets |
|---|---|---|
| Client HTTP/1.1 | Sì (TIdHTTP) | Sì (TsgcHTTPComponentClient, può usare backend Indy o ICS) |
| Server HTTP/1.1 | Sì (TIdHTTPServer) | Sì (TsgcWebSocketHTTPServer, gestisce HTTP + WS sulla stessa porta) |
| Client/server WebSocket | Nessun supporto nativo | RFC 6455 completo, permessage-deflate, sotto-protocolli, testato Autobahn |
| HTTP/2 (h2 + h2c) | No | Sì, layer HPACK + frame custom |
| HTTP/3 / QUIC | No | Sì (basato su msquic) |
| MQTT 3.1.1 e 5.0 | No | Sì, client e broker |
| AMQP 1.0 / 0.9.1 | No | Sì |
| STOMP, SSE, WAMP | No | Sì |
| WebRTC / P2P / STUN / TURN | No | Sì |
| CoAP e IoT cloud (AWS, Azure) | No | Sì |
| OpenAI, Anthropic, Gemini, MCP | No | Sì, componenti dedicati |
| FTP / SMTP / POP3 / IMAP | Sì | No (usa Indy per quelli) |
| Gratuito / commerciale | Gratuito, in stile MIT | Commerciale, diverse edizioni inclusa la Free |
| Versioni Delphi | D7 in su (varia per fork) | Da D7 a D13 |
| Manutenzione attiva | Community (IndyProject su GitHub) | Vendor, release mensili |
Dove Indy vince ancora
Se il tuo progetto è un client Internet classico — scaricare un file via HTTP, fare il post di una form, inviare un'email SMTP, recuperare la posta via IMAP, parlare con un vecchio server FTP — Indy stock è la risposta giusta. È gratuito, è incluso con l'IDE, l'API è familiare e non hai bisogno d'altro. Lo stesso vale per server TCP hobbystici e protocolli che Indy distribuisce nativamente (NNTP, IRC, Telnet, Whois). Per questi casi d'uso, aggiungere una libreria a pagamento è esagerato.
Indy è anche la scelta ovvia quando devi interoperare con codice che usa già tipi Indy — per esempio componenti che si aspettano un TIdSSLIOHandlerSocketOpenSSL o un TIdHTTPServerCommandHandler.
Dove sgcWebSockets è lo strumento giusto
Qualunque cosa coinvolga lo stack web moderno è significativamente più semplice con sgcWebSockets. Concretamente:
- WebSocket — il messaging full-duplex è una funzionalità di prima classe. Il server gestisce HTTP e WebSocket sulla stessa porta, gestisce i sotto-protocolli, supporta la compressione e si integra con l'auto-reconnect WatchDog out of the box.
- HTTP/2 e HTTP/3 — richiesti per le Apple Push Notification, i servizi Google e un numero crescente di REST API che hanno iniziato a imporre h2 come minimo. Indy non ha risposte qui.
- Broker di messaging — MQTT 5, AMQP 1.0, STOMP, WAMP e SSE sono tutti distribuiti come componenti pronti all'uso con TLS, riconnessione e autenticazione.
- Multimedia in tempo reale — WebRTC, ICE, STUN, TURN e DTLS-SRTP per audio/video e data channel compatibili con i browser.
- API AI e cloud — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe e qualche decina di altre sono incapsulate come componenti tipizzati invece che chiamate REST raw.
Performance e scaling
Il modello thread-per-connessione di Indy è semplice e corretto, ma limita il throughput pratico attorno a qualche migliaio di connessioni concorrenti su un tipico server Windows prima che il context switching diventi il collo di bottiglia. sgcWebSockets offre lo stesso backend Indy per compatibilità, più un trasporto server basato su IOCP su Windows che è stato benchmarkato a decine di migliaia di connessioni WebSocket concorrenti per processo. Per il puro throughput HTTP la differenza è minore, ma per connessioni di lunga durata (WebSocket, MQTT, SSE) il divario architetturale conta.
Anche il footprint di memoria per connessione idle è minore con il trasporto IOCP perché non c'è un thread OS dedicato per ogni socket. Su Linux il quadro è simile con server basati su epoll tramite il fork Indy che sgcWebSockets distribuisce.
Manutenzione e cadenza dei rilasci
Indy è mantenuto da un piccolo gruppo di volontari sul repository GitHub IndyProject. I rilasci sono lenti ma la codebase è stabile. Fix critici (compatibilità TLS, binding OpenSSL moderni) arrivano ma non sempre velocemente.
sgcWebSockets è un prodotto commerciale di eSeGeCe con rilasci mensili, un file di history pubblico e supporto vendor diretto. Le nuove versioni Delphi sono tipicamente supportate fin dal primo giorno — Delphi 13 è stato supportato dalla prima beta — e le nuove revisioni di protocollo (MQTT 5.0.1, HTTP/3 finale, aggiornamenti della spec MCP) escono in giorni invece che anni.
Licenza e prezzi
Indy è gratuito e viene distribuito con Delphi. sgcWebSockets è commerciale ma ha una Free Edition per uso non commerciale, più edizioni a pagamento (Standard, Professional, Enterprise, All-Access) con copertura di protocolli progressivamente più ampia. La maggior parte dei progetti commerciali può giustificare una licenza Professional single-developer con un solo cliente deployato.
Una semplice regola decisionale
Una regola pratica per il 2026:
- Usa Indy per SMTP/POP3/IMAP/FTP, per download HTTP di breve durata dentro una codebase Indy esistente, o per qualunque protocollo Internet classico che Indy già gestisce nativamente.
- Usa sgcWebSockets nel momento in cui WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT o qualunque API AI/REST entra in scena, o quando hai bisogno di un server che scali oltre qualche migliaio di connessioni.
- Usa entrambi nello stesso progetto — in effetti è il pattern più comune. Indy resta per il layer email e FTP, sgcWebSockets gestisce il layer real-time e delle API moderne, e condividono la stessa infrastruttura Indy SSL/IO sotto.
Considerazioni finali
Indy non va da nessuna parte — è il martello fidato in ogni toolbox Delphi. Ma i protocolli che definiscono l'Internet del 2026 (WebSocket, HTTP/2/3, MQTT, WebRTC, API AI) semplicemente non esistevano quando Indy fu progettato. sgcWebSockets riempie quel gap con una libreria focalizzata, attivamente mantenuta, supportata commercialmente, che si costruisce su Indy dove è utile e lo sostituisce dove necessario. Per i nuovi progetti che mirano a back-end moderni, la domanda non è più Indy o sgcWebSockets? — è come li combino?