Wann tiidbasearre PAC-regels in proxy kieze
In tiidregel yn in PAC kiest in proxy as it rûteleasjen evaluearre wurdt. It ûnthjit net om in besteande ferbining op in presys sekonde nei in nije útgong te ferpleatsen.
Jo kinne in PAC-regel skriuwe dy't moarns ien proxy weromjout en letter in oare. Mar út dy regel kinne jo net opmeitsje dat elke besteande browserferbining middeis fan útgong wikselet.
Funksjes lykas timeRange() dogge mei oan in rûteleasjebeslút. Se binne gjin eftergrûnplanner dy't tunnels slút, sockets migrearret of in proxyoanbieder freget om syn iepenbiere IP te rotearjen.
Hâld trije eveneminten apart:
- De browser evaluearret it PAC en krijt in rûte.
- De klant makket in ferbining of brûkt dy opnij neffens syn netwurkregels.
- De keazen tsjinst kiest it iepenbiere adres foar syn folgjende ferbining.
De tiidbetingst giet direkt oer it earste evenemint. In al aktive download of in langduorjende ferbining is in oare saak. Klantcaching en wergebrûk fan ferbiningen betsjutte ek dat 'it skript befettet in klokkontrôle' net genôch bewiis is foar in presys wikselplan.
As in taak in nije útgong nedich hat per sesje, oanfraach of tiidfinster, brûk dan in ynterface dat foar dy easke ûntwurpen is en ferifiearje it dokumintearre gedrach. In PAC kin kieze tusken einpunten, mar it definiearret net wat dy einpunten mei har eigen útgongsadressen dogge.
Tiidbasearre rûteleasjen kin noch hieltyd nuttich wêze foar in bewust netwurkbelied. Beskriuw it as it kiezen fan in rûte op it momint fan evaluaasje, net as in garandearre IP-rotaasjemechanisme.