Kiam temp-bazitaj PAC-reguloj elektas prokurilon
Tempa regulo en PAC elektas prokurilon kiam enkursigado estas taksata. Ĝi ne promesas movi ekzistantan konekton al nova eliro en preciza sekundo.
Vi povas skribi PAC-regulon, kiu matene redonas unu prokurilon kaj poste alian. Sed el tiu regulo vi ne povas konkludi, ke ĉiu ekzistanta retumila konekto ŝanĝas sian eliron tagmeze.
Funkcioj kiel timeRange() partoprenas en enkursiga decido. Ili ne estas fona planilo, kiu fermas tunelojn, migras ingojn aŭ petas de prokurila provizanto rotacii sian publikan IP.
Tenu tri eventojn aparte:
- La retumilo taksas la PAC-on kaj ricevas itineron.
- La kliento starigas aŭ reuzas konekton laŭ siaj retaj reguloj.
- La elektita servo elektas la publikan adreson por sia plua konekto.
La tempa kondiĉo rekte koncernas la unuan eventon. Jam aktiva elŝuto aŭ longdaŭra konekto estas alia afero. Klienta kaŝmemoro kaj reuzado de konektoj ankaŭ signifas, ke 'la skripto enhavas horloĝan kontrolon' ne estas sufiĉa pruvo de preciza ŝanĝhoraro.
Se tasko bezonas novan eliron por ĉiu seanco, peto aŭ tempa fenestro, uzu interfacon dizajnitan por tiu postulo kaj kontrolu ĝian dokumentitan konduton. PAC povas elekti inter finpunktoj, sed ĝi ne difinas, kion tiuj finpunktoj faras kun siaj propraj eliraj adresoj.
Temp-bazita enkursigado ankoraŭ povas esti utila por intenca reta politiko. Priskribu ĝin kiel elekton de itinero dum taksado, ne kiel garantiitan IP-rotacian mekanismon.