Dos librerías, dos trabajos distintos
Casi todo desarrollador Delphi ha usado Indy en algún momento. Viene en la caja con el IDE, lleva por aquí desde finales de los 90 y toda una generación de código de red Delphi está construida sobre TIdHTTP, TIdTCPClient, TIdSMTP y compañía. sgcWebSockets es una librería comercial mucho más reciente, centrada en los protocolos que han aparecido desde que se diseñó Indy — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — más un amplio catálogo de integraciones con APIs REST.
La pregunta más habitual en los foros de Embarcadero y en Stack Overflow es alguna variante de “¿Por qué pagaría por sgcWebSockets si Indy es gratis?”. La respuesta corta es que resuelven problemas distintos, y en muchos proyectos reales acabarás usando ambas. Este artículo recorre las diferencias prácticas en 2026 para que decidas cuál (o qué combinación) encaja con tu aplicación.
Qué hace en realidad cada librería
Indy es un kit TCP/UDP de propósito general con una larga lista de protocolos clásicos de Internet: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, más un framework de servidor TCP. Su diseño es thread-por-conexión e I/O bloqueante. No hay cliente ni servidor WebSocket nativos en el Indy de fábrica — tienes que añadirlo aparte, y varios proyectos comunitarios hacen exactamente eso con resultados desiguales.
sgcWebSockets es una librería focalizada y rica en protocolos, orientada a escenarios cliente/servidor modernos. Está organizada alrededor de un par núcleo TsgcWebSocketClient / TsgcWebSocketHTTPServer con add-ons opcionales para HTTP/2, HTTP/3 sobre QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), cifrado de extremo a extremo y más de 30 envoltorios de API (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp, etc.).
Un detalle importante y a menudo pasado por alto: sgcWebSockets usa Indy internamente como uno de sus backends de transporte. La fontanería TCP/TLS de varios componentes es un TIdTCPClient / TIdHTTPServer de Indy por debajo, así que instalar sgcWebSockets no reemplaza Indy — construye sobre él. La librería también ofrece transportes alternativos (estilo Synapse, ICS, SChannel) para escenarios donde Indy no es la mejor opción.
Comparación función a función
| Función | Indy (de fábrica) | sgcWebSockets |
|---|---|---|
| Cliente HTTP/1.1 | Sí (TIdHTTP) | Sí (TsgcHTTPComponentClient, puede usar backend Indy o ICS) |
| Servidor HTTP/1.1 | Sí (TIdHTTPServer) | Sí (TsgcWebSocketHTTPServer, gestiona HTTP + WS en el mismo puerto) |
| Cliente/servidor WebSocket | Sin soporte nativo | RFC 6455 completo, permessage-deflate, subprotocolos, testado con autobahn |
| HTTP/2 (h2 + h2c) | No | Sí, capa HPACK + frame propia |
| HTTP/3 / QUIC | No | Sí (basado en msquic) |
| MQTT 3.1.1 y 5.0 | No | Sí, cliente y broker |
| AMQP 1.0 / 0.9.1 | No | Sí |
| STOMP, SSE, WAMP | No | Sí |
| WebRTC / P2P / STUN / TURN | No | Sí |
| CoAP y IoT cloud (AWS, Azure) | No | Sí |
| OpenAI, Anthropic, Gemini, MCP | No | Sí, componentes dedicados |
| FTP / SMTP / POP3 / IMAP | Sí | No (usa Indy para esos) |
| Gratis / comercial | Gratis, estilo MIT | Comercial, varias ediciones incluida la Free |
| Versiones de Delphi | D7 en adelante (varía según el fork) | D7 hasta D13 |
| Mantenimiento activo | Comunidad (IndyProject en GitHub) | Fabricante, releases mensuales |
Dónde Indy sigue ganando
Si tu proyecto es un cliente clásico de Internet — descargar un archivo por HTTP, hacer post de un formulario, enviar un email SMTP, leer correo por IMAP, hablar con un servidor FTP viejo — el Indy de fábrica es la respuesta correcta. Es gratis, viene con el IDE, la API es familiar y no necesitas nada más. Lo mismo vale para servidores TCP de aficionado y protocolos que Indy soporta nativamente (NNTP, IRC, Telnet, Whois). Para esos casos, añadir una librería de pago es excesivo.
Indy es también la opción obvia cuando debes interoperar con código que ya usa tipos Indy — por ejemplo, componentes que esperan un TIdSSLIOHandlerSocketOpenSSL o un TIdHTTPServerCommandHandler.
Dónde sgcWebSockets es la herramienta correcta
Cualquier cosa que involucre la pila web moderna es notablemente más fácil con sgcWebSockets. En concreto:
- WebSocket — la mensajería full-duplex es una función de primera clase. El servidor maneja HTTP y WebSocket en el mismo puerto, gestiona subprotocolos, admite compresión y se integra de fábrica con el WatchDog de reconexión automática.
- HTTP/2 y HTTP/3 — requeridos por Apple Push Notifications, los servicios de Google y un número creciente de APIs REST que empiezan a exigir h2 como mínimo. Indy no tiene respuesta aquí.
- Brokers de mensajería — MQTT 5, AMQP 1.0, STOMP, WAMP y SSE vienen como componentes listos para usar con TLS, reconexión y autenticación.
- Multimedia en tiempo real — WebRTC, ICE, STUN, TURN y DTLS-SRTP para audio/vídeo y data channels compatibles con navegador.
- APIs de IA y cloud — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe y unas cuantas docenas más vienen envueltas como componentes tipados en vez de llamadas REST crudas.
Rendimiento y escalado
El modelo thread-por-conexión de Indy es simple y correcto, pero limita el throughput práctico a unos pocos miles de conexiones concurrentes en un servidor Windows típico antes de que el context switching se convierta en el cuello de botella. sgcWebSockets ofrece el mismo backend Indy por compatibilidad, más un transporte de servidor basado en IOCP en Windows que se ha medido con decenas de miles de conexiones WebSocket concurrentes por proceso. Para throughput HTTP puro la diferencia es menor, pero para conexiones de larga vida (WebSocket, MQTT, SSE) la brecha arquitectónica importa.
La huella de memoria por conexión inactiva también es menor con el transporte IOCP porque no hay un hilo de SO dedicado por socket. En Linux el panorama es similar con los servidores basados en epoll vía el fork de Indy que distribuye sgcWebSockets.
Mantenimiento y cadencia de releases
Indy lo mantiene un pequeño grupo de voluntarios en el repositorio IndyProject de GitHub. Las releases son lentas pero el código base es estable. Las correcciones críticas (compatibilidad TLS, bindings modernos de OpenSSL) llegan, pero no siempre rápido.
sgcWebSockets es un producto comercial de eSeGeCe con releases mensuales, un archivo de historial público y soporte directo del fabricante. Las nuevas versiones de Delphi suelen estar soportadas desde el primer día — Delphi 13 lo estuvo desde la primera beta — y las revisiones de protocolo nuevas (MQTT 5.0.1, HTTP/3 final, actualizaciones de la spec de MCP) llegan en días en lugar de en años.
Licencia y precio
Indy es gratis y viene con Delphi. sgcWebSockets es comercial pero tiene una Edición Free para uso no comercial, más ediciones de pago (Standard, Professional, Enterprise, All-Access) con cobertura de protocolos progresivamente más amplia. La mayoría de proyectos comerciales pueden justificar una licencia Professional single-developer con un solo cliente desplegado.
Una regla de decisión sencilla
Una regla pragmática para 2026:
- Usa Indy para SMTP/POP3/IMAP/FTP, para descargas HTTP de corta duración dentro de un código base Indy existente, o para cualquier protocolo clásico de Internet que Indy ya maneje nativamente.
- Usa sgcWebSockets en cuanto WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT o cualquier API IA/REST entre en escena, o cuando necesites un servidor que escale más allá de unos pocos miles de conexiones.
- Usa ambas en el mismo proyecto — ese es de hecho el patrón más común. Indy se queda con la capa de email y FTP, sgcWebSockets maneja la capa de tiempo real y APIs modernas, y comparten la misma infraestructura SSL/IO de Indy por debajo.
Reflexiones finales
Indy no se va a ningún lado — es el martillo fiable en toda caja de herramientas Delphi. Pero los protocolos que definen la internet de 2026 (WebSocket, HTTP/2/3, MQTT, WebRTC, APIs de IA) simplemente no existían cuando se diseñó Indy. sgcWebSockets llena ese hueco con una librería focalizada, mantenida activamente y con soporte comercial que construye sobre Indy donde es útil y la reemplaza donde es necesario. Para nuevos proyectos dirigidos a back-ends modernos, la pregunta ya no es ¿Indy o sgcWebSockets? — es ¿cómo las combino?