Maaari kang magsulat ng tuntuning PAC na nagbabalik ng isang proxy sa umaga at ng iba pa mamaya. Ngunit hindi mo maaaring ipahiwatig mula sa tuntuning iyon na bawat umiiral na koneksyon ng browser ay nagpapalit ng labasan sa tanghali.

Ang mga function tulad ng timeRange() ay lumalahok sa desisyon sa routing. Hindi sila isang background scheduler na nagsasara ng tunnel, naglilipat ng socket o humihiling sa isang provider ng proxy na paikutin ang pampublikong IP nito.

Paghiwalayin ang tatlong pangyayari:

  1. Sinusuri ng browser ang PAC at nakakakuha ng ruta.
  2. Nagtatatag o gumagamit muli ang client ng koneksyon ayon sa mga tuntunin nito sa network.
  3. Pinipili ng napiling serbisyo ang pampublikong address para sa susunod nitong koneksyon.

Ang kundisyon ng oras ay direktang may kinalaman sa unang pangyayari. Ang download na aktibo na o pangmatagalang koneksyon ay ibang usapin. Ang pag-cache ng client at muling paggamit ng mga koneksyon ay nangangahulugan ding ang 'may pagsusuri ng orasan ang script' ay hindi sapat na ebidensya ng tumpak na iskedyul ng paglilipat.

Kung ang isang gawain ay nangangailangan ng bagong labasan sa bawat session, kahilingan o window ng oras, gumamit ng interface na dinisenyo para sa pangangailangang iyon at i-verify ang dokumentadong pag-uugali nito. Maaaring pumili ang PAC sa mga endpoint, ngunit hindi nito tinutukoy kung ano ang ginagawa ng mga endpoint na iyon sa kanilang sariling mga address ng labasan.

Ang routing na batay sa oras ay maaari pa ring maging kapaki-pakinabang para sa sinadyang patakaran sa network. Ilarawan ito bilang pagpili ng ruta sa oras ng pagsusuri, hindi bilang garantisadong mekanismo ng pag-ikot ng IP.

Kaugnay na mga artikulo