د پروکسي شوي WebSocket له بیا نښلولو وروسته سیشن هم بیا رغوه

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

حتی هماغه پروکسي پای ټکی کېدای شي نوی بهرته وتونکی تړون جوړ کړي. بدل شوی وتونکی IP کېدای شي د منزل خپله د سیشن تګلاره هم فعاله کړي. نوی ساکټ د نوي تړون په توګه وګڼئ او د غوښتنلیک مستند شوی د بیا رغونې تبادله تعقیب کړئ. پریکړه وکړئ چې آیا کاري بهیر باید خپله پروکسي لاره وساتي کله چې بیا نښلول کیږي.

له وروستي URL څخه لږ څه زیات وساتئ

د بیا رغونې ګټور حالت کېدای شي مجاز سیشن هویت، غوښتل شوي ګډونونه، د وروستي تایید شوي پیښې پیژندونکی او هغه عملیات چې لا هم د تایید په تمه دي شامل وي. هغه ساحې د غوښتنلیک پروتوکول دي؛ WebSocket یو نړیوال د دوام ټوکن نه تعریفوي.

پریکړه وکړئ چې له کرسر څخه دوام ورکړئ، نوی انځور واخلئ یا تشه ومنئ. که د پیښو سرچینه د بیا غږولو انٹرفیس وړاندې نه کړي، نو ګړندی بیا نښلول نشي کولی ثابت کړي چې هیڅ پیغام نه دی ورک شوی.

دوه ځله لېږل کېدای شي دوه ځله کول وي

هغه پیغام چې د بندیدو مخکې په سیمه ییز ډول په قطار کې ایښودل شوی و، کېدای شي هیڅکله له کلاینټ څخه نه وي وتلی. بل کېدای شي سرور ته رسېدلی وي پداسې حال کې چې تایید یې ورک شو. هر نا-تایید شوی حکم په ناڅاپي ډول بیا لېږل هغه دوه حالتونه یو شان ګڼي.

چېرې چې شته، د خدمت د غوښتنې پیژندونکي، د idempotency ملاتړ یا د سازش میکانیزم وکاروئ. د لېږد بیا نښلول نشي کولی د غوښتنلیک یو عمل د بدلیدو وړ کړي یا په اتوماتيک ډول د هغه نقلونه لرې کړي.

د بیا نښلولو هڅې محدودې وساتئ او سرعت د غوښتنلیک تګلارې سره سم کړئ. RFC 6455 وروسته له غیر نورمالې بندیدو د شاتګ وړاندیز کوي؛ د کلاینټونو یوه ډله چې سمدلاسه بیا هڅه کوي کېدای شي د خنډ بار زیات کړي.

ثبت کړئ چې هرې هڅې کومه پروکسي لاره غوره کړه، خو د لارې بیا رغونه د غوښتنلیک بیا رغونې څخه جلا وساتئ. «بیا ونښلول شو» ګټور شاهد دی. «مات شو او د لا زیات کار سپارلو لپاره چمتو یو» هغه اضافي غوښتنلیک تبادله غواړي چې دا ثابتوي.