Trzy jednoczesne połączenia to decyzja o dopuszczeniu, a aby na nią odpowiedzieć, trzeba wiedzieć, które sloty są zajęte teraz, a nie co wydarzyło się w zeszłym miesiącu. Usługa może odmówić czwartej sesji na podstawie małej tabeli aktywnych rekordów i nigdy nie zbudować osi czasu. To stwierdzenie o mechanizmie, a nie o operatorze, i ta różnica ma znaczenie, gdy czytasz politykę prywatności. Poniższy model pokazuje, czego decyzja potrzebuje i co może odrzucić.

Mechanizm: tabela slotów, a nie dziennik

Najprostsza implementacja wiąże subskrypcję z maksymalnie trzema aktywnymi rekordami sesji. Każda dopuszczona sesja zajmuje jeden slot, a slot jest zwalniany, gdy usługa uzna, że sesja się zakończyła. Rekord potrzebuje wystarczająco konkretnej tożsamości, aby zwolnienie jednego połączenia nie zwalniało slotu innego połączenia; dlatego identyfikator sesji jest ważniejszy niż nazwa konta.

Zajętość i historia to różne struktury danych. Zajętość odpowiada na pytanie tak lub nie o teraźniejszość i można ją odrzucić w chwili zakończenia sesji. Historia to strumień zdarzeń tylko do dopisywania, a przetrwa, bo ktoś zdecydował się ją zachować. Usługa może mieć jedno, oba albo żadne z nich.

Ta różnica jest niewidoczna z zewnątrz. Widoczny limit połączeń współgra z maleńkim licznikiem w pamięci, współdzieloną tabelą bazy danych i pełnym archiwum zdarzeń z pulpitem nawigacyjnym. Nic w limicie nie mówi, który z nich działa.

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

Dlaczego model bieżący nadal wymaga koordynacji

Utracone połączenie może nie zostać od razu rozpoznane jako zakończone. Brama czeka na limit czasu, awarię keepalive lub zatrzymanie księgowania, a dopóki któreś z nich nie nadejdzie, slot pozostaje zajęty. Użytkownik, który połączy się ponownie w tym oknie, widzi odmowę niemającą nic wspólnego z czwartym urządzeniem.

Zrestartowany serwer musi uzgodnić swój stan, a kilka bram obsługujących to samo konto potrzebuje wspólnej decyzji. Inaczej konto może przekroczyć swój limit, łącząc się z różnych lokalizacji. Współdzielony lub odtwarzalny stan to rozwiązuje, a współdzielony stan jest wymogiem projektowym, nie dowodem nadzoru.

Nic z tej koordynacji nie wymaga historii przeglądania. Brama przekazująca pakiety nie musi wiedzieć, które witryny odwiedziła sesja, aby liczyć sesje, a te dwa strumienie danych obsługują zwykle całkowicie różne komponenty.

Trzymanie licznika w pamięci również nie czyni powiązanych faktów anonimowymi. Gdy usługa działa, rekord powiązany z subskrypcją ujawnia, że konto ma aktywne połączenia, a zarówno dostęp do tego stanu, jak i jego czas życia są warte pytania.

Dokąd ten stan trafia później

Pytanie o prywatność nie brzmi, czy serwer potrafi liczyć. Zapytaj, co dzieje się z zakończoną sesją: rekord jest usuwany, czy staje się zdarzeniem w serii monitoringu? Następnie zapytaj, które inne komponenty widziały to samo zdarzenie, ponieważ logi uwierzytelniania, rekordy księgowe i kopie zapasowe mogą każde zachować kopię, którą ścieżka egzekwowania odrzuciła.

Księgowanie RADIUS to najjaśniejszy przykład. Para Start i Stop istnieje, aby wspierać rozliczenia i kontrolę sesji, i tworzy rekord połączenia niezależnie od tego, czy ktoś kiedykolwiek pyta o niego jako historię. Usługa, która egzekwuje limity przez księgowanie, zachowuje więc z założenia więcej niż tabelę slotów.

Usuwanie też ma kształt. Rekord usunięty z tabeli bieżącej może przetrwać w kopii zapasowej wykonanej godzinę wcześniej, a okres przechowywania tej kopii jest osobnym oświadczeniem polityki. Czytanie tylko magazynu podstawowego daje niepełną odpowiedź.

Zadaj pytanie w kategoriach pól

Wytyczne RFC 6973 dotyczące minimalizacji danych wiążą gromadzone i przechowywane dane z obsługiwanym celem. Zastosowane tutaj, użytecznym pytaniem jest, jakich pól zadanie jednoczesnego dopuszczenia naprawdę potrzebuje i jaki cel uzasadnia zachowanie każdego z nich po zakończeniu tego zadania.

Precyzyjne oświadczenie usługi oddziela bieżący stan połączenia używany do egzekwowania limitu od wszelkich rekordów zachowanych po zakończeniu i wymienia inne systemy w zakresie obietnicy. Zdanie, które mówi tylko, że egzekwowane są trzy połączenia, nie ustala ani że archiwum istnieje, ani że go nie ma.

Gdy cykl życia jest niejasny, zapisz to jako pytanie o przechowywanie bez odpowiedzi, a nie jako wyrok. Obecność limitu nie jest dowodem ukrytej historii, a prawdopodobne wyjaśnienie bieżącego stanu nie jest audytem dostawcy.

Powiązane artykuły