د VPN د اړیکو محدودیتونه: ژوندی حالت د ساتل شوې تاریخچې پر وړاندې

درې سملاسي اړیکې د منلو پرېکړه ده، او د هغې د ځواب لپاره باید وپوهېږو چې همدا اوس کوم ځایونه بوخت دي، نه دا چې تېره میاشت څه وشول۔ یوه خدمت کولای شي څلورمه ناسته د فعالو ریکارډونو له کوچنۍ جدول څخه رد کړي او هېڅکله د وخت کرښه جوړه نکړي۔ دا د میکانزم په اړه خبره ده، نه د چلونکي، او کله چې د محرمیت تګلاره لولې دا توپیر مهم دی۔ لاندې ماډل ښیي چې پرېکړې ته څه اړین دي او څه کولای شي وشړي۔

میکانزم: د ځایونو جدول، نه ثبت

ساده پلي کول ګډون له تر درېیو فعالو ناستې ریکارډونو سره تړي۔ هره منل شوې ناسته یو ځای اخلي، او ځای هغه وخت خالي کېږي چې خدمت پرېکړه وکړه چې هغه ناسته پای ته رسېدلې ده۔ ریکارډ ته دومره ځانګړې پېژندنه پکار ده چې د یوې اړیکې خوشې کول د بلې اړیکې ځای خوشې نکړي؛ نو ځکه د ناستې پېژندونکی د حساب له نوم مهمتر دی۔

بوختوالی او تاریخچه بېلابېلې ډېټا جوړښتونه دي۔ بوختوالی د اوسني په اړه هو-یا-نه پوښتنې ته ځواب وایي، او د ناستې په پای کې د هماغه شېبې په ترڅ کې وشړل شي۔ تاریخچه یوازې د زیاتېدونکو پېښو بهیر دی، او ژوندی پاتې کېږي ځکه چې یو چا یې د ساتلو انتخاب کړی۔ یو خدمت کولای شي یو، دواړه یا هېڅ هم ولري۔

دا توپیر له بهر نه ښکاري۔ لیدل کېدونکی د اړیکو محدودیت د حافظې له کوچني شمېروونکي، شریکې ډېټابیس جدول او د ډشبورډ سره بشپړې پېښې آرشیف سره سمون خوري۔ د محدودیت په اړه هېڅ نه وایي چې کوم یو روان دی۔

ولې ژوندی ماډل لا هم همغږۍ ته اړتیا لري

له لاسه وتلې اړیکه ممکن سملاسي د پای ته رسېدلې په توګه ونه پېژندل شي۔ ګېټوې د وخت پای، د keepalive ناکامۍ یا د حساب بندېدو ته انتظار کوي، او تر څو چې له دغو یو نه وي رسېدلی، ځای بوخت پاتې کېږي۔ هغه کارن چې په دې موده کې بیا وصل شي، داسې رد ویني چې له څلورمې وسیلې سره هېڅ تړاو نه لري۔

بیا پیل شوی سرور باید خپل حالت سره سمون کړي، او څو ګېټوې چې یو حساب ته خدمت کوي یوې ګډې پرېکړې ته اړتیا لري۔ که نه، حساب کولای شي په بېلابېلو ځایونو کې د وصلېدو له لارې خپله ونډه واوړي۔ شریک یا بیا رغېدونکی حالت دا حل کوي، او شریک حالت د ډیزاین اړتیا ده، نه د څارنې ثبوت۔

د دې همغږۍ هېڅ برخه د براوز کولو تاریخچې ته اړتیا نه لري۔ هغه ګېټوې چې بستې لېږدوي د ناستو د شمېرلو لپاره نه پوهېږي چې یوې ناستې کوم وېبځایونه کتلي، او دا دوه ډېټا بهیرونه معمولاً بشپړ بېلابېل برخې اداره کوي۔

شمېرل د حافظې په دننه کې ساتل هم اړوند حقایق بېنومه نه کوي۔ تر څو چې خدمت روان وي، د ګډون سره تړلی ریکارډ ښیي چې یو حساب فعالې اړیکې لري، او هم د دې حالت ته لاسرسی او هم د هغې عمر د پوښتنې وړ دي۔

هغه حالت بیا چېرته ځي

د محرمیت پوښتنه دا نه ده چې سرور شمېرلای شي که نه۔ وپوښتئ چې د پای ته رسېدلې ناستې سره څه کېږي: ریکارډ لرې کېږي، که په څارنې لړ کې پېښه کېږي؟ بیا وپوښتئ چې هماغه پېښه کومو نورو برخو لیدلې، ځکه چې د پېژندنې لاګونه، حسابي ریکارډونه او بیکاپونه هر یو کولای شي هغه کاپي وساتي چې د پلي کولو لارې وشړله۔

RADIUS حساب تر ټولو روښانه بېلګه ده۔ د Start او Stop جوړه د بلنې او د ناستې د کنټرول د ملاتړ لپاره شته، او د اړیکې ریکارډ جوړوي، پرته له دې چې څوک یې کله د تاریخچې په توګه وپوښتي۔ نو ځکه هغه خدمت چې محدودیتونه د حساب له لارې پلي کوي، په جوړښت کې له ځایونو جدول څخه زیات ساتي۔

د مخ کولو بڼه هم شته۔ له ژوندي جدول څخه لرې شوی ریکارډ کولای شي په یو ساعت دمخه اخیستل شوي بیکاپ کې پاتې شي، او د هغه بیکاپ ساتنې موده خپله تګلاره بیانوي۔ یوازې لومړنی ذخیره لوستل نیمګړی ځواب درکوي۔

پوښتنه د ساحو په بڼه وکړئ

د RFC 6973 د ډېټا کموالي لارښود راټول شوي او ساتل شوي ډېټا له هغه هدف سره تړي چې خدمت ورته کېږي۔ دلته پلي کول، ګټوره پوښتنه دا ده چې د سملاسي منلو دندې واقعاً کومې ساحې ته اړتیا لري، او کوم هدف د دې دندې له پای وروسته د هرې یوې ساتل توجیه کوي۔

دقیق خدمت بیان ژوندی د اړیکې حالت چې د ونډې پلي کولو لپاره کارول کېږي له پای وروسته ساتل شوي هر ریکارډ څخه بېلوي، او د ژمنې په چوکاټ کې نور سیستمونه نوموي۔ هغه جمله چې یوازې وایي درې اړیکې پلي کېږي، نه د آرشیف شتون او نه نشتوالی ثابتوي۔

کله چې د ژوند چرخه روښانه نه وي، هغه د حکم پر ځای د ناځواب شوې ساتنې پوښتنې په توګه ثبت کړئ۔ د محدودیت شتون د پټې تاریخچې ثبوت نه دی، او د ژوندي حالت باور وړ تشریح د برابرونکي پلټنه نه ده۔