შეგიძლიათ დაწეროთ PAC წესი, რომელიც დილით ერთ პროქსის აბრუნებს, ხოლო მოგვიანებით სხვას. მაგრამ ამ წესიდან ვერ დაასკვნით, რომ ყოველი არსებული ბრაუზერის კავშირი შუადღეს გასასვლელს იცვლის.

timeRange()-ის მსგავსი ფუნქციები მარშრუტიზაციის გადაწყვეტილებაში მონაწილეობენ. ისინი ფონური დამგეგმავი არ არიან, რომელიც გვირაბებს ხურავს, სოკეტებს გადაადგილებს ან პროქსის მომწოდებელს საჯარო IP-ის ბრუნვას სთხოვს.

სამი მოვლენა ცალკე შეინახეთ:

  1. ბრაუზერი აფასებს PAC-ს და იღებს მარშრუტს.
  2. კლიენტი ამყარებს ან ხელახლა იყენებს კავშირს თავისი ქსელური წესების მიხედვით.
  3. არჩეული სერვისი ირჩევს საჯარო მისამართს შემდგომი კავშირისთვის.

დროის პირობა პირდაპირ პირველ მოვლენას ეხება. უკვე აქტიური ჩამოტვირთვა ან ხანგრძლივი კავშირი სხვა საკითხია. კლიენტის ქეშირება და კავშირების ხელახალი გამოყენება ასევე ნიშნავს, რომ 'სკრიპტი საათის შემოწმებას შეიცავს' არ არის საკმარისი მტკიცებულება ზუსტი გადართვის გრაფიკისთვის.

თუ დავალებას სჭირდება ახალი გასასვლელი ყოველი სესიისთვის, მოთხოვნისთვის ან დროის ფანჯრისთვის, გამოიყენეთ ამ მოთხოვნისთვის შექმნილი ინტერფეისი და გადაამოწმეთ მისი დოკუმენტირებული ქცევა. PAC-ს შეუძლია ბოლო წერტილებს შორის არჩევანი, მაგრამ არ განსაზღვრავს, რას აკეთებენ ეს წერტილები თავიანთი გასასვლელი მისამართებით.

დროზე დაფუძნებული მარშრუტიზაცია მაინც შეიძლება სასარგებლო იყოს განზრახ ქსელური პოლიტიკისთვის. აღწერეთ ის როგორც მარშრუტის არჩევა შეფასების დროს, და არა როგორც გარანტირებული IP ბრუნვის მექანიზმი.

დაკავშირებული სტატიები