Három egyidejű kapcsolat egy beengedési döntés, és a megválaszolásához azt kell tudni, mely helyek foglaltak éppen most, nem azt, hogy mi történt múlt hónapban. Egy szolgáltatás elutasíthat egy negyedik munkamenetet az aktív rekordok kis táblája alapján, és soha nem épít idővonalat. Ez a mechanizmusról szóló állítás, nem az üzemeltetőről, és a különbség számít, amikor adatvédelmi irányelvet olvasol. Az alábbi modell megmutatja, mire van szüksége a döntésnek, és mit dobhat el.

A mechanizmus: helytábla, nem napló

A legegyszerűbb megvalósítás egy előfizetést legfeljebb három aktív munkamenet-rekordhoz rendel. Minden beengedett munkamenet egy helyet foglal, és a hely akkor szabadul fel, amikor a szolgáltatás úgy dönt, hogy az a munkamenet véget ért. A rekordnak elég egyedi azonosítóra van szüksége ahhoz, hogy az egyik kapcsolat felszabadítása ne szabadítsa fel egy másik kapcsolat helyét; ezért a munkamenet-azonosító fontosabb, mint a fiók neve.

A foglaltság és az előzmény különböző adatszerkezetek. A foglaltság egy igen-nem kérdésre válaszol a jelenről, és el lehet dobni abban a pillanatban, amikor a munkamenet véget ér. Az előzmény csak hozzáfűzhető eseményfolyam, és azért marad meg, mert valaki úgy döntött, hogy megtartja. Egy szolgáltatásnak lehet az egyik, mindkettő vagy egyik sem.

A különbség kívülről láthatatlan. Egy látható kapcsolati limit összeegyeztethető egy parányi memóriabeli számlálóval, egy közös adatbázistáblával és egy irányítópulttal ellátott teljes eseményarchívummal. A limitről semmi nem árulja el, melyik fut.

What is storedWhy it exists
Active session slotsTo admit or refuse the next connection
Session event logTo investigate or bill later
Monitoring seriesTo watch capacity and error rates
Backup copiesTo restore any of the above

Miért van mégis összehangolásra szükség az élő modellnél

Lehet, hogy egy elveszett kapcsolatot nem ismernek fel azonnal befejezettként. Az átjáró időtúllépésre, keepalive-hibára vagy elszámolási leállásra vár, és amíg valamelyik meg nem érkezik, a hely foglalt marad. Az a felhasználó, aki ebben az ablakban újra csatlakozik, olyan elutasítást lát, amelynek semmi köze egy negyedik eszközhöz.

Egy újraindított kiszolgálónak össze kell hangolnia az állapotát, és több átjárónak, amely ugyanazt a fiókot szolgálja ki, közös döntésre van szüksége. Különben egy fiók túllépheti a keretét azzal, hogy különböző helyekhez csatlakozik. A megosztott vagy helyreállítható állapot ezt megoldja, és a megosztott állapot tervezési követelmény, nem a megfigyelés bizonyítéka.

Ennek az összehangolásnak egyik része sem igényel böngészési előzményeket. Egy csomagokat továbbító átjárónak nem kell tudnia, mely oldalakat látogatta egy munkamenet ahhoz, hogy munkameneteket számoljon, és ezt a két adatfolyamot általában teljesen különböző összetevők kezelik.

A számláló memóriában tartása sem teszi névtelenné a kapcsolódó tényeket. Amíg a szolgáltatás fut, az előfizetéshez kötött rekord elárulja, hogy egy fióknak aktív kapcsolatai vannak, és mind az állapothoz való hozzáférés, mind annak élettartama kérdezésre érdemes.

Hová kerül az állapot utána

Az adatvédelmi kérdés nem az, hogy a kiszolgáló tud-e számolni. Kérdezd meg, mi történik egy befejezett munkamenettel: eltávolítják a rekordot, vagy eseménnyé válik egy megfigyelési sorozatban? Utána kérdezd meg, mely más összetevők látták ugyanazt az eseményt, mert a hitelesítési naplók, az elszámolási rekordok és a biztonsági mentések mindegyike őrizhet egy példányt, amelyet a kényszerítési útvonal elvetett.

A RADIUS-elszámolás a legvilágosabb példa. A Start és Stop pár a számlázás és a munkamenet-vezérlés támogatására létezik, és létrehozza a kapcsolat rekordját, függetlenül attól, hogy valaki valaha előzményként lekérdezi-e. Egy szolgáltatás, amely elszámolás révén kényszeríti ki a limiteket, ezért felépítésénél fogva többet őriz egy helytáblánál.

A törlésnek is van formája. Az élő táblából eltávolított rekord megmaradhat egy egy órával korábban készült biztonsági mentésben, és annak a mentésnek a megőrzési ideje önálló szabályzati nyilatkozat. Ha csak az elsődleges tárolót olvasod, hiányos választ kapsz.

Tegyük fel a kérdést mezők szerint

Az RFC 6973 adatminimalizálási útmutatása összeköti a gyűjtött és tárolt adatokat a szolgált céllal. Ide alkalmazva a hasznos kérdés az, mely mezőkre van ténylegesen szüksége az egyidejű beengedés feladatának, és milyen cél igazolja mindegyik megtartását a feladat vége után.

Egy pontos szolgáltatási nyilatkozat elválasztja a keret kikényszerítésére használt élő kapcsolati állapotot a megszűnés után megőrzött bármilyen rekordtól, és megnevezi a többi rendszert az ígéret hatókörén belül. Egy mondat, amely csak azt mondja, hogy három kapcsolatot kényszerítenek ki, nem bizonyítja sem azt, hogy létezik archívum, sem azt, hogy nem.

Amikor az életciklus nem világos, jegyezd fel megválaszolatlan megőrzési kérdésként, ne ítéletként. Egy limit jelenléte nem bizonyíték rejtett előzményre, és az élő állapot valószínű magyarázata nem a szolgáltató auditja.

Kapcsolódó cikkek