Wanneer tydgebaseerde PAC-reels 'n proxy kies
'n Tydreël in 'n PAC kies 'n proxy wanneer die roetering geëvalueer word. Dit belowe nie om 'n bestaande verbinding op 'n presiese sekonde na 'n nuwe uitgang te skuif nie.
Jy kan 'n PAC-reël skryf wat soggens een proxy teruggee en later 'n ander. Uit daardie reël kan jy nie aflei dat elke bestaande blaaierverbinding om middagete van uitgang wissel nie.
Funksies soos timeRange() neem deel aan 'n roeteringsbesluit. Hulle is nie 'n agtergrondsbeplanner wat tonnels sluit, snitte migreer of 'n proxyverskaffer vra om sy openbare IP te roteer nie.
Hou drie gebeure apart:
- Die blaaier evalueer die PAC en kry 'n roete.
- Die kliënt bou of hergebruik 'n verbinding volgens sy netwerkstreëls.
- Die gekose diens kies die openbare adres vir sy verder verbinding.
'n Tydvoorwaarde raak direk die eerste gebeurtenis. 'n Aflaai of langdurige verbinding wat reeds aktief is, is 'n ander saak. Kliëntkas en hergebruik van verbindings beteken ook dat 'die skrip bevat 'n horlosiecontrole' nie genoeg bewyse is van 'n presiese skakelprogram nie.
As 'n taak 'n nuwe uitgang per sessie, versoek of tydvenster nodig het, gebruik 'n koppelvlak wat vir daardie vereiste ontwerp is en verifieer sy gedokumenteerde gedrag. 'n PAC kan tussen eindpunte kies, maar dit definieer nie wat daardie eindpunte met hul eie uitgangsadresse doen nie.
Tydgebaseerde roetering kan steeds nuttig wees vir 'n doelbewuste netwerkbeleid. Beskryf dit as die keuse van 'n roete tydens evaluering, nie as 'n gewaarborgde IP-rotasiemeganisme nie.