Gallwch ysgrifennu rheol PAC sy'n dychwelyd un dirprwy yn y bore a dirprwy arall yn ddiweddarach. Ond ni ellir casglu o'r rheol honno fod pob cysylltiad porwr presennol yn newid allanfa ganol dydd.

Mae ffwythiannau fel timeRange() yn cymryd rhan mewn penderfyniad llwybro. Nid ydynt yn amserlynnwr cefndir sy'n cau twneli, yn mudo socedau nac yn gofyn i ddarparwr dirprwy gylchdroi ei IP cyhoeddus.

Cadwch dri digwyddiad ar wahân:

  1. Mae'r porwr yn gwerthuso'r PAC ac yn cael llwybr.
  2. Mae'r cleient yn sefydlu neu'n ailddefnyddio cysylltiad yn ôl ei reolau rhwydwaith.
  3. Mae'r gwasanaeth a ddewiswyd yn dewis y cyfeiriad cyhoeddus ar gyfer ei gysylltiad nesaf.

Mae'r amod amser yn ymwneud yn uniongyrchol â'r digwyddiad cyntaf. Mae llwythiad sydd eisoes yn actif neu gysylltiad hirhoedlog yn fater arall. Mae cacing cleient ac ailddefnyddio cysylltiadau hefyd yn golygu nad yw 'mae'r sgript yn cynnwys archwiliad cloc' yn dystiolaeth ddigonol o amserlen newid fanwl.

Os oes angen allanfa newydd ar dasg ar gyfer pob sesiwn, cais neu ffenestr amser, defnyddiwch ryngwyneb a gynlluniwyd ar gyfer y gofyniad hwnnw a gwirio ei ymddygiad dogfennedig. Gall PAC ddewis ymhlith diweddbwyntiau, ond nid yw'n diffinio beth y mae'r diweddbwyntiau hynny yn ei wneud gyda'u cyfeiriadau allanfa eu hunain.

Gall llwybro amserol fod yn ddefnyddiol o hyd ar gyfer polisi rhwydwaith bwriadedig. Disgrifiwch ef fel dewis llwybr ar adeg gwerthuso, nid fel mecanwaith cylchdroi IP gwarantedig.

Erthyglau cysylltiedig