Limoj de VPN-konektoj: viva stato kontraŭ konservata historio
Limigo de tri konektoj bezonas vivan staton de niĉoj, ne retuman historion: kion la mekanismo devas konservi, kion ĝi povas forĵeti, kaj kien tiu stato iras poste.
Tri samtempaj konektoj estas akcepta decido, kaj por respondi ĝin oni devas scii, kiuj niĉoj estas okupitaj ĝuste nun, ne kio okazis pasintmonate. Servo povas rifuzi kvaran sesion per malgranda tabelo de aktivaj rikordoj kaj neniam konstrui tempolinion. Tio estas aserto pri la mekanismo, ne pri la funkciiganto, kaj la diferenco gravas, kiam vi legas privatpolitan regularon. La suba modelo montras, kion la decido bezonas kaj kion ĝi povas forĵeti.
La mekanismo: niĉa tabelo, ne protokolo
La plej simpla efektivigo ligas abonon al ĝis tri aktivaj sesiaj rikordoj. Ĉiu enlasita sesio okupas unu niĉon, kaj la niĉo liberiĝas, kiam la servo decidas, ke tiu sesio finiĝis. La rikordo bezonas identecon sufiĉe specifan, por ke liberigo de unu konekto ne liberigu la niĉon de alia konekto; tial la sesia identigilo pli gravas ol la konta nomo.
Okupiteco kaj historio estas malsamaj datumstrukturoj. Okupiteco respondas jes-aŭ-ne demandon pri la nuna momento kaj povas esti forĵetita en la momento, kiam la sesio finiĝas. Historio estas aldonebla fluo de eventoj, kaj ĝi postvivas ĉar iu elektis konservi ĝin. Servo povas havi unu, ambaŭ aŭ neniun.
La distingo estas nevidebla de ekstere. Videbla konekta limo kongruas kun malgrandega enmemora nombrilo, kun dividata datumbaza tabelo kaj kun plena eventa arkivo kun panelo. Nenio pri la limo diras al vi, kiu el ili funkcias.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Kial la viva modelo ankoraŭ bezonas kunordigon
Perdita konekto eble ne tuj estos rekonita kiel finita. La enirejo atendas tempolimon, keepalive-fiaskon aŭ kontadan halton, kaj ĝis unu el tiuj alvenas, la niĉo restas okupita. Uzanto, kiu rekonektas dum tiu fenestro, vidas rifuzon, kiu tute ne rilatas al kvara aparato.
Restartigita servilo devas akordigi sian staton, kaj pluraj enirejoj servantaj la saman konton bezonas komunan decidon. Alie konto povas superi sian kvoton per konekto al diversaj lokoj. Komunigita aŭ restaŭrebla stato solvas tion, kaj komunigita stato estas projektpostulo, ne pruvo de gvatado.
Neniu el tiu kunordigo postulas retumajn historiojn. Enirejo, kiu plusendas pakaĵojn, ne bezonas scii, kiujn retejojn sesio vizitis, por nombri sesiojn, kaj la du datumfluojn kutime traktas tute malsamaj komponantoj.
Teni nombrilon en memoro ankaŭ ne igas la rilatajn faktojn anonimaj. Dum la servo funkcias, abonligita rikordo malkaŝas, ke konto havas aktivajn konektojn, kaj kaj la aliro al tiu stato kaj ĝia vivodaŭro indas esti demanditaj.
Kien la stato poste iras
La privateca demando ne estas, ĉu la servilo povas nombri. Demandu, kio okazas al finita sesio: ĉu la rikordo estas forigita, aŭ ĉu ĝi fariĝas evento en monitorada serio? Poste demandu, kiuj aliaj komponantoj vidis la saman eventon, ĉar aŭtentigaj protokoloj, kontadaj rikordoj kaj savkopioj povas ĉiu teni kopion, kiun la plenumvojo forĵetis.
RADIUS-kontado estas la plej klara ekzemplo. Paro Start kaj Stop ekzistas por subteni fakturaron kaj sesian regadon, kaj ĝi kreas rikordon de la konekto sendepende de tio, ĉu iu iam demandas ĝin kiel historion. Servo, kiu plenumas limojn per kontado, do laŭkonstrua retenas pli ol niĉan tabelon.
Ankaŭ forigo havas formon. Rikordo forigita el la viva tabelo povas daŭri en savkopio farita unu horon pli frue, kaj la retenperiodo de tiu savkopio estas propra politika deklaro. Legi nur la ĉefan konservejon donas nekompletan respondon.
Formulu la demandon per kampoj
La datenminimumiga gvidilo de RFC 6973 ligas la kolektitajn kaj konservitajn datumojn al la celo, kiun ili servas. Aplikite ĉi tie, la utila demando estas, kiujn kampojn la tasko de samtempa enlaso efektive bezonas, kaj kiu celo pravigas konservi ĉiun el ili post kiam tiu tasko finiĝas.
Preciza priserva deklaro apartigas la vivan konektan staton uzatan por plenumi la kvoton de iuj ajn rikordoj retenitaj post finiĝo, kaj ĝi nomas la aliajn sistemojn ene de la amplekso de la promeso. Frazo, kiu diras nur, ke tri konektoj estas plenumataj, establas nek ke arkivo ekzistas nek ke ĝi ne ekzistas.
Kiam la vivociklo estas neklara, registru ĝin kiel sensolvan retenan demandon anstataŭ verdikton. La ĉeesto de limo ne estas pruvo de kaŝita historio, kaj verŝajna klarigo pri viva stato ne estas revizio de la provizanto.