Heartbeat, újracsatlakozás és állapot-visszaszinkronizálás

Célok

A lecke végére el tudod magyarázni, hogyan ismerhető fel a megszakadt kapcsolat, hogyan csatlakozzon újra a kliens a terhelés növelése nélkül, és hogyan állítható helyre az alkalmazási állapot.

Miért kell?

A tartós kapcsolat megszakadhat hálózatváltás, proxy-időtúllépés, szerverkiesés vagy kliensalvás miatt. A kliensnek és a szervernek együtt kell megterveznie, hogyan ismerik fel a megszakadást és hogyan állítják helyre az állapotot. A kapcsolat helyreállítása nem az állapot helyreállítása.

Heartbeat és időkeret

Az egyik fél rendszeres életjelet vár. A határidőnek összhangban kell lennie a proxy tétlenségi időkorlátjával, a hálózati késéssel és a kliens korlátaival: túl rövid határ felesleges bontást okoz, túl hosszú későn ismeri fel a kiesést. A protokoll Ping/Pong kerete (10.1) erre alkalmas; ha az API nem ad hozzáférést, alkalmazási heartbeat használható. Egy háttérbe került lap vagy egy alvó eszköz késleltetheti az időzítőket, ezért a szerver ne feltételezzen pontos ütemet. A pong a kapcsolat és a feldolgozó életképességét mutatja, nem egy korábbi üzleti parancs sikerét.

Újracsatlakozás backoff-fal

Azonnali, végtelen újracsatlakozás sok kliensnél túlterhelheti az éppen újraindult szervert. Az AWS leírása szerint az exponenciális backoff (a várakozás próbálkozásonként nő) és a jitter (véletlen eltérés) szórja a próbálkozásokat; korlátot kell szabni a várakozásnak és a próbálkozások számának. A nem javuló hitelesítési hibát nem szabad hálózati ismétlésként kezelni. A szerver 1001 („going away”) kóddal zárhatja le a kapcsolatot leállításkor; a tömeges bontás újracsatlakozási hullámot okoz, ezért fokozatosság és jitter kell (10.4).

stateDiagram-v2
  [*] --> Kapcsolodas
  Kapcsolodas --> Szinkronizalas: kapcsolat létrejött
  Kapcsolodas --> Varakozas: átmeneti hiba
  Szinkronizalas --> Aktiv: állapot és feliratkozások rendben
  Aktiv --> Varakozas: megszakadás
  Varakozas --> Kapcsolodas: backoff lejárt
  Kapcsolodas --> Leallitva: végleges elutasítás
  Aktiv --> Leallitva: felhasználó kilép
  Leallitva --> [*]

Az Aktív állapot nem a kapcsolat felépülésével kezdődik, hanem a szükséges hitelesítés és szinkronizálás után. A kliens így nem mutat friss adatként lemaradt állapotot.

Visszajátszás eseményazonosítóval

A kliens megőrizheti az utolsó alkalmazott eseményazonosítót, és újracsatlakozáskor ettől a ponttól kér folytatást (ahogy az SSE Last-Event-ID mechanizmusa, 9.3). A szervernek ehhez tényleg elérhető és jogosultság szerint szűrt eseménynaplót kell tartania; egy lastId mező önmagában nem teremt tartós visszajátszást. Ha a megőrzési idő lejárt vagy a pozíció ismeretlen, a szerver resync-jelzést ad: a kliens friss pillanatképet (snapshot) kér, és annak verzióhatárától veszi át az eseményeket.

Pillanatkép és folyam versenyhelyzete

Ha a kliens először pillanatképet kér, majd feliratkozik, közben történhet kihagyott változás. Ha először folyamot nyit, majd pillanatképet kér, az események és a pillanatkép összefésülése szükséges. Egy közös verzió vagy kurzor dönti el, mely események vannak már benne a pillanatképben. Az ismételt eseményt azonosító vagy verzió alapján ismerheti fel a kliens; deltaüzenetnél a hiányzó előzmény újraolvasást igényel, teljes állapotüzenetnél az újabb verzió felülírhatja a régebbit (8.3).

Jellemzők

Szempont	Újracsatlakozás és resync
Irány	Kétirányú: a kliens kéri a folytatást, a szerver visszajátszik
Kezdeményező	A kliens az újracsatlakozást; a szerver a resync-jelzést
Kapcsolat tartóssága	Megszakadás után új kapcsolat
Késleltetés	Megszakadás alatt nincs adat; a visszajátszás pótolja
Terhelés	Reconnect-hullám leállításkor; visszajátszás költsége
Hibatűrés	Visszajátszás vagy pillanatkép; idempotens eseménykezelés
Mikor jó?	Rövid megszakadások, megőrzött napló
Mikor nem?	Ha nincs megőrzés, és az állapot nem kérdezhető le külön

Gyakori tévhitek

Állítás	Pontosítás
„Az újracsatlakozás után minden folytatódik.”	A kimaradt események visszajátszás nélkül elvesznek.
„Elég azonnal újracsatlakozni.”	Backoff és jitter nélkül túlterhel.
„A pong sikeres üzleti műveletet bizonyít.”	Csak a kapcsolat és a feldolgozó életét.
„A lastId mező elég a folytatáshoz.”	A szervernek tényleges naplót kell tartania.

Röviden

• A heartbeat időkeretét a proxy tétlenségi időkorlátjához kell igazítani.
• Újracsatlakozás: exponenciális backoff + jitter, felső korláttal.
• Az állapotot visszajátszással vagy pillanatképpel kell helyreállítani, közös verzióhatárral.
• Az Aktív állapot a szinkronizálás után kezdődik.

Ellenőrző kérdések

1. Miért nem elég új socketet nyitni a kapcsolatvesztés után?
2. Hogyan zárnád be a pillanatkép és a folyam közötti rést?
3. Milyen állapotot mutasson a felület szinkronizálás közben?

Források

• Timeouts, retries and backoff with jitter (AWS Builders' Library) — backoff és jitter.
• RFC 6455, 5.5 és 7.4 — kontrollkeretek, lezárási kódok.
• HTML Standard: Server-sent events — az id/Last-Event-ID mechanizmus.