sgcWebSockets 2026.7: clustering, berichtgeschiedenis, async / await en geharde clients

sgcWebSockets 2026.7 draait om draaien in productie. Je kunt een WebSocket applicatie nu over meerdere servers verspreiden en kanalen, pub/sub en presence over al die servers laten werken. Kanalen kunnen hun recente berichten onthouden, zodat een client die wegvalt en terugkomt alsnog krijgt wat hij gemist heeft. Clients verbinden opnieuw met exponentiële backoff en jitter in plaats van in de pas op de server te beuken, de verzendwachtrij kan begrensd worden zodat één trage consument het servergeheugen niet kan opsouperen, en de HTTP client kreeg een reeks beschermingen tegen redirects die credentials lekken, tegen afgezwakte TLS en tegen antwoorden zonder groottelimiet.

Daarbovenop is er een async / await laag voor Delphi, gzip en deflate op de HTTP servers, de nieuwe HTTP QUERY methode, identiteitsverificatie voor end-to-end encryptie, OAuth2 op de MCP client, en een lange lijst met fixes. Dit artikel is de rondleiding. Elke sectie linkt naar het artikel dat de functie in detail behandelt.

Clustering over meerdere servers

De nieuwe TsgcWSCluster component koppelt meerdere sgcWebSockets servers tot één logische server. Een bericht dat op node A wordt gepubliceerd bereikt subscribers die met node B verbonden zijn, en presence geeft de lijst van het hele cluster terug in plaats van alleen die van de lokale node. Er zijn twee backplanes beschikbaar: een ingebouwde mesh, waarbij de nodes rechtstreeks met elkaar praten en je niets extra installeert, en Redis Pub/Sub voor grotere omgevingen (Enterprise).

uses
  sgcWebSocket, sgcWebSocket_Protocols, sgcWebSocket_Cluster;

oCluster := TsgcWSCluster.Create(nil);
oCluster.EngineType  := clusterMesh;          // no extra infrastructure
oCluster.ClusterPort := 5410;                 // this node's mesh listener
oCluster.Peers.Add('192.168.1.101:5410');     // the other nodes
oCluster.Attach(oProtocol);                   // cluster this protocol's pub/sub
oCluster.Start;

Lees meer: WebSocket servers schalen over meerdere nodes.

Berichtgeschiedenis en herstel na een reconnect

De sgc protocol server kan nu de laatste N berichten van elk kanaal bewaren, optioneel met een time-to-live. Wanneer een client opnieuw verbindt en zich opnieuw abonneert, stuurt hij de offset van het laatste bericht dat hij echt gezien heeft, en de server speelt alles opnieuw af wat er gepubliceerd is terwijl hij weg was. Er verandert niets in je clientcode behalve de resubscribe die je toch al doet, en het geheel staat uit tenzij je het inschakelt.

oProtocol.History.Enabled    := True;
oProtocol.History.Size       := 1000;   // last 1000 messages per channel
oProtocol.History.TTLSeconds := 3600;   // optional: also expire after 1 hour

Lees meer: Berichtgeschiedenis en herstel na een reconnect.

async / await, en een Connect die echt wacht

De nieuwe unit sgcBase_AsyncAwait brengt tasks en futures naar de bibliotheek. Je kunt wachten op een HTTP request, een WebSocket verbinding of een AI chat completion zonder ook maar één event handler te koppelen, het resultaat doorschakelen met ThenProc en OnError, en een task annuleren op een manier die de onderliggende request ook echt afbreekt.

In dezelfde geest blokkeert Connect nu tot de verbinding volledig tot stand is gebracht en niet alleen gestart, en wacht Disconnect tot de socket echt gesloten is. Dat sluit een race die bij snelle reconnects toesloeg. Als een connect of een send mislukt, staat de reden in de nieuwe property LastError, en er is een overload van Connect die de foutmelding rechtstreeks aan je teruggeeft, zodat je een fout kunt onderzoeken zonder je op OnError te abonneren.

var
  vError: string;
begin
  if sgcWebSocketClient1.Connect(10000) then
    sgcWebSocketClient1.WriteData('hello')
  else
    ShowMessage('Connect failed: ' + sgcWebSocketClient1.LastError);

  // or get the reason back directly from the call
  if not sgcWebSocketClient1.Connect(vError, 10000) then
    ShowMessage('Connect failed: ' + vError);
end;

Lees meer: async / await in Delphi.

De HTTP client harden

Een redirect is de makkelijkste manier om een token kwijt te raken. Als een server je geauthenticeerde request beantwoordt met een 302 naar een andere host, herhaalt de client daar vrolijk de Authorization en Cookie headers. 2026.7 voegt StripAuthOnCrossHostRedirect toe om ze bij een cross-site redirect te laten vallen, en NoInsecureRedirect om een redirect te weigeren die HTTPS afzwakt naar gewoon HTTP.

Antwoorden kunnen nu ook begrensd worden, met MaxChunkSize voor een enkel stuk van een chunked antwoord en MaxResponseSize voor het totaal. RejectPublicSuffixCookies gooit cookies weg die voor veel te brede domeinen worden opgeëist, zoals "com" of "co.uk". Voor uploads is er Expect: 100-continue, dat de server om toestemming vraagt voordat er een grote body wordt verstuurd, en een chunked request body om een upload te streamen waarvan je de grootte nog niet kent.

oHTTP.StripAuthOnCrossHostRedirect := True;
oHTTP.NoInsecureRedirect           := True;
oHTTP.MaxResponseSize              := 10 * 1024 * 1024;  // 10 MB, 0 = unlimited
oHTTP.MaxChunkSize                 := 1024 * 1024;       // 1 MB per chunk
oHTTP.RejectPublicSuffixCookies    := True;

Al deze schakelaars staan standaard uit, en voor geen ervan hoef je naar het low-level HTTP object te grijpen: ze zijn ook published op de kant-en-klare API clients (AI/LLM, crypto exchanges, OAuth2, Google Cloud, WhatsApp, AWS SQS, WebPush). De beschermingen voor redirects en groottes zitten ook op de HTTP/2 client, en HTTP/3 krijgt de limiet op de antwoordgrootte erbij. Lees meer: De HTTP client harden.

Retries, backoff en jitter

De WatchDog verbond vroeger opnieuw op een vast interval, wat betekent dat duizend clients die de server kwijtraken allemaal op hetzelfde moment terugkomen. Hij ondersteunt nu exponentiële backoff met een vermenigvuldiger, een plafond en een willekeurige jitter, zodat de vloot zichzelf uitsmeert. Het vaste interval blijft de standaard, dus er verandert niets tot je erom vraagt.

De HTTP client kreeg een eigen retry policy: opnieuw proberen bij een instelbare lijst statuscodes, elke keer langer wachten, en de Retry-After hint van de server respecteren wanneer die er een meestuurt. De OpenAI, Anthropic en Gemini clients gebruiken hem ook.

sgcWebSocketClient1.WatchDog.Backoff           := wdbExponential;
sgcWebSocketClient1.WatchDog.BackoffMultiplier := 2.0;   // double every attempt
sgcWebSocketClient1.WatchDog.MaxInterval       := 60;    // seconds, the ceiling
sgcWebSocketClient1.WatchDog.Jitter            := 0.2;   // up to 20% random spread

Lees meer: Exponentiële backoff, jitter en Retry-After.

Backpressure op de verzendwachtrij

Wanneer een client trager leest dan jij schrijft, stapelen de berichten in de wachtrij zich op in het servergeheugen. Je kunt het aantal openstaande berichten per verbinding nu begrenzen met QueueOptions.MaxQueueSize en kiezen wat er gebeurt zodra die grens bereikt wordt: het oudste bericht laten vallen, het nieuwste laten vallen, of de verbinding verbreken. Het nieuwe event OnSendBufferFull vuurt voordat er iets wordt weggegooid, zodat je het kunt loggen, tellen, of het weggooien kunt tegenhouden voor een verbinding die je je niet kunt veroorloven af te kappen. De wachtrij is standaard onbegrensd.

oServer.QueueOptions.MaxQueueSize   := 1000;
oServer.QueueOptions.OverflowPolicy := qopDropOldest;  // or qopDropNewest, qopDisconnect

Lees meer: Limieten op de verzendwachtrij voor trage WebSocket clients.

gzip en deflate op de HTTP server

De HTTP servers kunnen hun antwoorden nu comprimeren zodra de client Accept-Encoding meegeeft. Het geldt voor bestanden die vanuit DocumentRoot geserveerd worden en voor antwoorden die je zelf opbouwt in OnCommandGet, het slaat bodies onder een minimumgrootte over en ook contenttypes die er niet kleiner van worden, en het is ook beschikbaar op de HTTP.sys server. Compressie staat standaard uit, en voorlopig worden alleen HTTP/1.1 antwoorden gecomprimeerd.

sgcWebSocketHTTPServer1.HTTPCompression.Enabled := True;
sgcWebSocketHTTPServer1.HTTPCompression.Level   := 6;     // 1..9
sgcWebSocketHTTPServer1.HTTPCompression.MinSize := 1024;  // bytes

Lees meer: gzip en deflate compressie op de HTTP server.

De HTTP QUERY methode

QUERY is een nieuwe HTTP methode van de IETF die een zoekopdracht in de request body verstuurt zoals een POST, maar veilig en cachebaar blijft zoals een GET, zodat je query niet langer in een URL met een lengtelimiet geperst hoeft te worden. 2026.7 implementeert hem op de HTTP/1.x, HTTP/2, HTTP/3 en REST clients, en de servers en de proxy verwerken hem.

vResult := oClient.Query('https://api.example.org/contacts', oQuery);

Lees meer: De nieuwe HTTP QUERY methode in Delphi.

E2EE identiteitsverificatie

End-to-end encryptie houdt de payload privé, maar zegt op zichzelf niets over wie er aan de andere kant zit. Een server of relay in het midden kan elke kant zijn eigen sleutel geven en alles meelezen. In 2026.7 kan elke kant zijn encryptiesleutel ondertekenen met een langlevende identiteitssleutel, en de andere kant verifieert die handtekening, zodat een stilzwijgende sleutelwissel gedetecteerd wordt in plaats van geaccepteerd.

Het werkt voor één op één gesprekken en voor groepschats, voegt events toe om de identiteit van een peer goed te keuren of vast te pinnen en om je te waarschuwen wanneer de identiteitssleutel van een peer verandert, en het staat standaard uit en is volledig compatibel met 2026.6 peers.

E2EE.E2EE_Options.Identity.Enabled    := True;
E2EE.E2EE_Options.Identity.PrivateKey := LoadIdentityPrivateKey;  // PEM
E2EE.E2EE_Options.Identity.PublicKey  := LoadIdentityPublicKey;   // PEM
E2EE.OnE2EEVerifyPeerIdentity := OnE2EEVerifyPeerIdentityEvent;
E2EE.OnE2EEKeyChange          := OnE2EEKeyChangeEvent;

Lees meer: E2EE identiteitsverificatie.

OAuth2 voor de MCP client, en de Identity Assertion grant

De MCP client kan zich nu authenticeren met OAuth2 in plaats van met een statische API key. Hij haalt het token zelf op, bewaart het in de cache tot het verloopt en ververst het, en als OAuth2 aanstaat krijgt het voorrang boven de API key. Daarnaast krijgt de OAuth2 client een nieuw grant type, de Identity Assertion Authorization Grant, die een identiteit van het ene domein doorgeeft aan het andere: de client doorloopt de hele exchange met meerdere stappen voor je en vuurt events af zodat je elke stap kunt volgen.

MCPClient.MCPOptions.AuthenticationOptions.OAuth2.Enabled := True;
MCPClient.MCPOptions.AuthenticationOptions.OAuth2.GrantType := auth2ClientCredentials;
MCPClient.MCPOptions.AuthenticationOptions.OAuth2.TokenURL := 'https://auth.example.com/oauth2/token';
MCPClient.MCPOptions.AuthenticationOptions.OAuth2.ClientId := 'YOUR_CLIENT_ID';
MCPClient.MCPOptions.AuthenticationOptions.OAuth2.ClientSecret := 'YOUR_CLIENT_SECRET';

Lees meer: OAuth2 voor de MCP Client.

Crypto feeds: resubscribe en rate limiting

Tot nu toe was de socket na een weggevallen marktdata verbinding weer online zodra de WatchDog hem terughaalde, maar was je nergens meer op geabonneerd tot je elke subscription zelf opnieuw afspeelde. De exchange clients kunnen dat nu voor je doen: zet Resubscribe := True en je streams worden na een reconnect hersteld. Het dekt Binance, Kraken, Coinbase en zo'n veertien andere exchanges, plus de sessiegebaseerde feed van XTB. De standaardwaarde is False.

De REST API clients krijgen een optionele rate limiter aan clientzijde, zodat een burst aan requests je geen tijdelijke ban bij een exchange oplevert. Begrens hoeveel requests je in een tijdvenster verstuurt, en kies of een request boven het budget wacht of geweigerd wordt. Staat standaard uit.

oBinance.RateLimit.Enabled     := True;
oBinance.RateLimit.IntervalMs  := 60000;   // one minute window
oBinance.RateLimit.MaxRequests := 1000;
oBinance.RateLimit.Behavior    := rlbWait;

Lees meer: Resubscribe en de rate limiter aan clientzijde.

Kleinere toevoegingen

• TLS preset. Elk TLS options object publiceert nu een Preset property. Met TLSOptions.Preset := tlspSecureDefaults zet je certificaatverificatie, TLS 1.2 of hoger, en controle van de hostnaam in één regel aan. De standaard, tlspCustom, laat je huidige instellingen ongemoeid.
• Eigen HTTP sessieklasse. Wijs je eigen afstammeling van TIdHTTPSession toe aan de SessionClass van de HTTP server voordat je hem start, en je kunt je eigen data in de sessie bewaren, terwijl het sessie id, de cookie, de timeout en het opruimen precies blijven werken zoals voorheen. Heb je volledige controle nodig over waar sessies leven, dan kun je ook je eigen SessionList toewijzen.
• RFC 2253 certificaat helpers. Nieuwe functies lezen het subject en de issuer van een certificaat als een standaard RFC 2253 distinguished name string.
• WinHTTP WebSocket client. Hij ondersteunt nu token/bearer en URL logins zoals de standaardclient, stelt het OnHandshake event beschikbaar zodat je je eigen headers aan de verbindingsrequest kunt toevoegen, en kan een logbestand schrijven met connects, disconnects en elk tekst en binair bericht dat verstuurd en ontvangen wordt. OAuth2, JWT en sessie logins zijn daar nog steeds niet beschikbaar, omdat hij de ingebouwde netwerkstack van Windows gebruikt en Indy niet bevat.

Fixes en hardening

2026.7 bevat een lange lijst met fixes. In plaats van ze allemaal te herhalen, hier waar ze bij elkaar op neerkomen.

Geheugenveiligheid en hardening van de parsers. Leesacties voorbij het einde van de buffer zijn opgelost in de MQTT 5 client (een broker die meer data claimde dan hij verstuurde), de AMQP 1.0 client (het decoderen van UUID's), de STUN/TURN parser (waaronder een oneindige lus en IPv6 adressen), het WebRTC SCTP datakanaal en de frame scanner voor ruwe TCP. De UDP client en server, inclusief DTLS, geven een socket niet langer twee keer vrij en laten hem bij een disconnect niet meer bungelen. Er zijn interne plafonds toegevoegd waar een zich misdragende peer het geheugen anders onbegrensd kon laten groeien: de MQTT wachtrij met openstaande berichten, de subscriptions per verbinding van het sgc protocol, de openstaande calls van de WAMP server, de trailer regels van een chunked antwoord en de nestdiepte van AMQP field tables.

HTTP/2. Een plafond op de gedecomprimeerde grootte (standaard 64 MB) dicht een out-of-memory gat met "zip bomb" antwoorden, de limiet op de antwoordgrootte kan niet langer omzeild worden door het laatste deel van een antwoord, en een mislukte request faalt nu meteen in plaats van de hele timeout uit te zitten.

Cryptografie en willekeur. De WebAuthn server, de OAuth2 authorization server en de ingebouwde HTTP sessie ids gebruiken nu een cryptografisch veilige generator voor willekeurige getallen, challenges zijn eenmalig te gebruiken, en geheimen worden in constante tijd vergeleken (client secret, JWT handtekening, HTTP API Basic wachtwoord). Een JWT met een geldige handtekening maar een verkeerde claim wordt nu geweigerd in plaats van geaccepteerd. Met StrictVerify aan in OpenSSL wordt het certificaat ook tegen de hostnaam gecontroleerd, zodat een geldig certificaat dat voor een andere host is uitgegeven geweigerd wordt. Verbindingen naar een IP adres en bestaande instellingen blijven ongemoeid.

Server-Sent Events. Een gestreamd antwoord dat meerdere events in één leesactie afleverde, of een event dat over twee leesacties verdeeld was, verloor alles behalve het eerste. Dit is opgelost, waarmee streaming per token voor de AI/LLM clients hersteld is. Bij OpenAI streaming chat werd bovendien de stream vlag niet gezet, dus die streamt nu net als de andere providers.

Exchange clients. Kraken request ids lopen nu strikt op, BitMEX stuurt zijn vervaltijd in seconden in plaats van in milliseconden, MEXC ondertekent de gecodeerde parameters die hij daadwerkelijk verstuurt, Cryptorobotics verwisselt niet langer twee waarden in by-hash calls, Deribit ververst zijn login token voordat het verloopt, en de Forex client meldt de fout die hij eerder inslikte bij het lezen van het account id.

Lazarus en Free Pascal. Drie compilatiefixes: de interfaces van de JSON unit gebruiken nu de juiste calling convention per platform (ze compileerden niet op Linux), de Forex client roept geen functie meer aan die alleen in Delphi bestaat om het getalformaat te lezen, en de unit voor de post-quantum sleuteluitwisseling hangt niet langer af van size_t.

Er staat meer in history.txt, waaronder de gRPC client (gelijktijdige calls konden elkaars antwoorden ontvangen, en een mislukte send werd als succes gemeld), de OpenAPI server (het laden van de spec is nu thread-safe en je handlers draaien niet langer terwijl een interne lock vastgehouden wordt), een lek van serververbindingen en sockets bij elke mislukte login, een crash bij OpenAI antwoorden zonder "message" veld zoals die van Ollama en LM Studio, een gerepareerde WriteAndWaitData op de WinHTTP client, en het redigeren van geheimen in de log van de HTTP client, zodat het aanzetten van logging niet langer tokens in leesbare tekst naar schijf schrijft.

De .NET editie

sgcWebSockets .NET 2026.7 richt zich op de HTTP client. Hij levert dezelfde set beschermingen als de Delphi editie: credentials verwijderen bij een cross-site redirect, een blokkade op een afzwakking van HTTPS naar HTTP, plafonds op de grootte per chunk en op het totale antwoord, het weigeren van public-suffix cookies, Expect: 100-continue en chunked request bodies. Ze zijn beschikbaar op de HTTP client componenten en op de kant-en-klare API clients (de AI/LLM clients, OAuth2, Google Cloud, WhatsApp, AWS SQS, WebPush), en dezelfde beschermingen voor redirects en groottes zitten op de HTTP/2 client. De fixes voor de afhandeling van redirects en het verlopen van cookies zitten er ook in. Alles staat standaard uit.

Upgraden

2026.7 is een drop-in upgrade voor bestaande 2026.x projecten. Elke nieuwe functie in deze release staat standaard uit: clustering, berichtgeschiedenis, backoff, het plafond op de verzendwachtrij, HTTP compressie, de beschermingen in de client, E2EE identiteitsverificatie en de resubscribe van de exchanges moeten allemaal expliciet aangezet worden, dus het installeren van de nieuwe build verandert geen enkel gedrag tot je er zelf voor kiest.

Klanten met een actief abonnement kunnen de nieuwe build downloaden uit het klantengedeelte, of via esegece.com/products/websockets/download.

Vragen, feedback of hulp bij de migratie? Neem contact op. Je krijgt antwoord van de mensen die de code hebben geschreven.