Pots escriure una regla PAC que retorni un proxy al matí i un altre més tard. Però no pots inferir d'aquesta regla que totes les connexions existents del navegador canviïn de sortida al migdia.

Funcions com timeRange() participen en una decisió d'encaminament. No són un planificador en segon pla que tanqui túnels, migri sockets o demani a un proveïdor de proxy que roti la seva IP pública.

Mantingues tres esdeveniments separats:

  1. El navegador avalua el PAC i obté una ruta.
  2. El client estableix o reutilitza una connexió segons les seves regles de xarxa.
  3. El servei triat escull l'adreça pública per a la seva connexió posterior.

La condició de temps afecta directament el primer esdeveniment. Una descàrrega ja activa o una connexió de llarga durada és una altra qüestió. La memòria cau del client i la reutilització de connexions també fan que «l'script conté una comprovació del rellotge» no sigui proves suficients d'un calendari de canvi precís.

Si una tasca necessita una sortida nova per sessió, petició o finestra de temps, fes servir una interfície dissenyada per a aquest requisit i verifica el seu comportament documentat. Un PAC pot triar entre punts finals, però no defineix què fan aquests punts finals amb les seves pròpies adreces de sortida.

L'encaminament basat en el temps encara pot ser útil per a una política de xarxa intencionada. Descriu-lo com a tria d'una ruta en el moment de l'avaluació, no com a mecanisme garantit de rotació d'IP.

Articles relacionats