Dwie biblioteki, dwa różne zadania
Prawie każdy deweloper Delphi w pewnym momencie używał Indy. Dostarczane jest razem ze środowiskiem IDE, istnieje od późnych lat 90., a całe pokolenie kodu sieciowego Delphi zbudowane jest na TIdHTTP, TIdTCPClient, TIdSMTP i pokrewnych. sgcWebSockets to znacznie nowsza biblioteka komercyjna skupiona na protokołach, które pojawiły się od czasu zaprojektowania Indy — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — plus duży katalog integracji REST API.
Najczęstsze pytanie na forach Embarcadero i Stack Overflow to jakaś wariacja na temat „Dlaczego miałbym płacić za sgcWebSockets, skoro Indy jest darmowe?”. Krótka odpowiedź brzmi: rozwiązują różne problemy i w wielu prawdziwych projektach skończysz, używając obu. Ten artykuł omawia praktyczne różnice w 2026 roku, żebyś mógł zdecydować, która z nich (lub które połączenie) pasuje do Twojej aplikacji.
Co każda biblioteka faktycznie robi
Indy to wielofunkcyjny zestaw narzędzi TCP/UDP z długą listą klasycznych protokołów internetowych: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, plus framework serwera TCP. Jego konstrukcja opiera się na modelu wątek-na-połączenie i blokującym I/O. W standardowej Indy nie ma natywnego klienta ani serwera WebSocket — trzeba go doczepić, a kilka projektów społecznościowych robi to dokładnie, z mieszanymi wynikami.
sgcWebSockets to skoncentrowana, bogata w protokoły biblioteka skierowana na nowoczesne scenariusze klient/serwer. Zorganizowana jest wokół pary rdzeniowej TsgcWebSocketClient / TsgcWebSocketHTTPServer z opcjonalnymi dodatkami dla HTTP/2, HTTP/3 nad QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), szyfrowania end-to-end oraz ponad 30 owijek API (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp itp.).
Ważny i często pomijany szczegół: sgcWebSockets wewnętrznie używa Indy jako jednego ze swoich backendów transportowych. Hydraulika TCP/TLS dla kilku komponentów to pod spodem Indy TIdTCPClient / TIdHTTPServer, więc instalacja sgcWebSockets nie zastępuje Indy — buduje na nim. Biblioteka oferuje również alternatywne transporty (w stylu Synapse, ICS, SChannel) dla scenariuszy, w których Indy nie jest najlepszym wyborem.
Porównanie funkcja po funkcji
| Funkcja | Indy (standard) | sgcWebSockets |
|---|---|---|
| Klient HTTP/1.1 | Tak (TIdHTTP) | Tak (TsgcHTTPComponentClient, może używać backendu Indy lub ICS) |
| Serwer HTTP/1.1 | Tak (TIdHTTPServer) | Tak (TsgcWebSocketHTTPServer, obsługuje HTTP + WS na tym samym porcie) |
| Klient/serwer WebSocket | Brak natywnej obsługi | Pełne RFC 6455, permessage-deflate, podprotokoły, testowane autobahn |
| HTTP/2 (h2 + h2c) | Nie | Tak, własny HPACK + warstwa ramek |
| HTTP/3 / QUIC | Nie | Tak (oparte na msquic) |
| MQTT 3.1.1 i 5.0 | Nie | Tak, klient i broker |
| AMQP 1.0 / 0.9.1 | Nie | Tak |
| STOMP, SSE, WAMP | Nie | Tak |
| WebRTC / P2P / STUN / TURN | Nie | Tak |
| CoAP i chmura IoT (AWS, Azure) | Nie | Tak |
| OpenAI, Anthropic, Gemini, MCP | Nie | Tak, dedykowane komponenty |
| FTP / SMTP / POP3 / IMAP | Tak | Nie (do tego użyj Indy) |
| Darmowa / komercyjna | Darmowa, licencja w stylu MIT | Komercyjna, kilka edycji w tym Free |
| Wersje Delphi | D7 i wyżej (zależy od forka) | D7 do D13 |
| Aktywne utrzymanie | Społeczność (IndyProject na GitHubie) | Producent, comiesięczne wydania |
Gdzie Indy nadal wygrywa
Jeśli Twój projekt to klasyczny klient internetowy — pobranie pliku przez HTTP, wysłanie formularza, wysłanie maila SMTP, pobranie poczty przez IMAP, rozmowa ze starym serwerem FTP — standardowe Indy jest właściwą odpowiedzią. Jest darmowe, dołączone do IDE, API jest znajome i nie potrzebujesz niczego więcej. To samo dotyczy hobbystycznych serwerów TCP i protokołów, które Indy natywnie dostarcza (NNTP, IRC, Telnet, Whois). Dla tych przypadków użycia dodawanie płatnej biblioteki to przesada.
Indy to także oczywisty wybór, kiedy musisz współpracować z kodem, który już używa typów Indy — na przykład z komponentami, które oczekują TIdSSLIOHandlerSocketOpenSSL lub TIdHTTPServerCommandHandler.
Gdzie sgcWebSockets jest właściwym narzędziem
Wszystko, co dotyczy nowoczesnego stosu webowego, jest znacznie łatwiejsze z sgcWebSockets. Konkretnie:
- WebSocket — komunikacja dwukierunkowa pełnodupleksowa jest funkcją pierwszej klasy. Serwer obsługuje HTTP i WebSocket na tym samym porcie, zarządza podprotokołami, wspiera kompresję i od razu integruje się z automatycznym ponownym łączeniem WatchDog.
- HTTP/2 i HTTP/3 — wymagane dla Apple Push Notifications, usług Google i rosnącej liczby REST API, które zaczęły wymuszać minimum h2. Indy nie ma tutaj odpowiedzi.
- Brokery komunikatów — MQTT 5, AMQP 1.0, STOMP, WAMP i SSE są dostarczane jako gotowe komponenty z TLS, ponownym łączeniem i uwierzytelnianiem.
- Multimedia w czasie rzeczywistym — WebRTC, ICE, STUN, TURN i DTLS-SRTP dla kompatybilnego z przeglądarką audio/video i kanałów danych.
- API AI i chmury — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe i kilkadziesiąt innych są opakowane jako typowane komponenty zamiast surowych wywołań REST.
Wydajność i skalowanie
Model wątek-na-połączenie Indy jest prosty i poprawny, ale ogranicza praktyczną przepustowość do kilku tysięcy jednoczesnych połączeń na typowym serwerze Windows, zanim przełączanie kontekstu stanie się wąskim gardłem. sgcWebSockets oferuje ten sam backend Indy dla kompatybilności plus oparty na IOCP transport serwera na Windows, który został przetestowany na dziesiątkach tysięcy jednoczesnych połączeń WebSocket na proces. Dla czystej przepustowości HTTP różnica jest mniejsza, ale dla długotrwałych połączeń (WebSocket, MQTT, SSE) luka architektoniczna ma znaczenie.
Ślad pamięciowy na połączenie bezczynne jest również niższy przy transporcie IOCP, ponieważ nie ma dedykowanego wątku OS na gniazdo. Na Linuksie obraz jest podobny dzięki serwerom opartym na epoll przez fork Indy, który dostarcza sgcWebSockets.
Utrzymanie i tempo wydań
Indy jest utrzymywane przez małą grupę wolontariuszy w repozytorium GitHub IndyProject. Wydania są powolne, ale baza kodu stabilna. Krytyczne poprawki (kompatybilność TLS, nowoczesne powiązania OpenSSL) rzeczywiście trafiają, ale nie zawsze szybko.
sgcWebSockets to produkt komercyjny od eSeGeCe z comiesięcznymi wydaniami, publicznym plikiem historii i bezpośrednim wsparciem producenta. Nowe wersje Delphi są zazwyczaj wspierane od pierwszego dnia — Delphi 13 było wspierane od pierwszej bety — a nowe rewizje protokołów (MQTT 5.0.1, HTTP/3 final, aktualizacje specyfikacji MCP) trafiają w ciągu dni, a nie lat.
Licencja i ceny
Indy jest darmowe i dostarczane z Delphi. sgcWebSockets jest komercyjne, ale ma edycję Free do użytku niekomercyjnego oraz płatne edycje (Standard, Professional, Enterprise, All-Access) z stopniowo szerszym pokryciem protokołów. Większość projektów komercyjnych może uzasadnić licencję Professional dla jednego dewelopera z jednym wdrożonym klientem.
Prosta zasada decyzyjna
Pragmatyczna reguła kciuka na 2026 rok:
- Użyj Indy dla SMTP/POP3/IMAP/FTP, dla krótkotrwałych pobrań HTTP wewnątrz istniejącej bazy kodu Indy lub dla dowolnego klasycznego protokołu internetowego, który Indy obsługuje natywnie.
- Użyj sgcWebSockets w momencie, gdy do gry wchodzą WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT lub dowolne AI/REST API, lub kiedy potrzebujesz serwera, który skaluje się powyżej kilku tysięcy połączeń.
- Użyj obu w tym samym projekcie — to w rzeczywistości najczęstszy wzorzec. Indy pozostaje dla warstwy poczty i FTP, sgcWebSockets obsługuje warstwę czasu rzeczywistego i nowoczesnych API, a obie współdzielą tę samą infrastrukturę Indy SSL/IO pod spodem.
Podsumowanie
Indy nigdzie się nie wybiera — to zaufany młotek w każdej skrzynce narzędziowej Delphi. Ale protokoły, które definiują internet 2026 (WebSocket, HTTP/2/3, MQTT, WebRTC, API AI), po prostu nie istniały, kiedy Indy było projektowane. sgcWebSockets wypełnia tę lukę skoncentrowaną, aktywnie utrzymywaną, komercyjnie wspieraną biblioteką, która buduje na Indy tam, gdzie jest to przydatne, i zastępuje je tam, gdzie jest to konieczne. Dla nowych projektów ukierunkowanych na nowoczesne back-endy pytanie nie brzmi już Indy czy sgcWebSockets? — brzmi jak je połączyć?