عندما تختار قواعد PAC الزمنية وكيلاً

يمكنك كتابة قاعدة PAC تعيد وكيلاً في الصباح وآخر لاحقاً. لكن لا يمكنك أن تستنتج من تلك القاعدة أن كل اتصال متصفح قائم يبدل مخرجه عند الظهر.

دوال مثل timeRange() تشارك في قرار التوجيه. وهي ليست مجدولاً خلفياً يغلق الأنفاق أو ينقل المقابس أو يطلب من مزود وكيل تدوير عنوان IP العام الخاص به.

افصل بين ثلاثة أحداث:

1. يقيّم المتصفح ملف PAC ويحصل على مسار.
2. ينشئ العميل اتصالاً أو يعيد استخدام اتصال وفق قواعد الشبكة لديه.
3. تختار الخدمة المحددة العنوان العام لاتصالها اللاحق.

شرط الوقت يتعلق بالحدث الأول مباشرة. أما التنزيل النشط أو الاتصال طويل الأمد فهو مسألة أخرى. كما أن تخزين العميل وإعادة استخدام الاتصالات يعنيان أن عبارة «يحتوي السكربت على فحص للساعة» ليست دليلاً كافياً على جدول تبديل دقيق.

إذا كانت المهمة تحتاج مخرجاً جديداً لكل جلسة أو طلب أو نافذة زمنية، فاستخدم واجهة مصممة لذلك الشرط وتحقق من سلوكها الموثق. يستطيع PAC الاختيار بين نقاط نهاية، لكنه لا يحدد ما تفعله تلك النقاط بعناوين المخرج الخاصة بها.

قد يظل التوجيه الزمني مفيداً لسياسة شبكة مقصودة. صِفه بأنه اختيار مسار عند التقييم، لا كآلية مضمونة لتدوير IP.