ຫຼັງຈາກເຊື່ອມຕໍ່ WebSocket ຜ່ານພຣັອກຊີຄືນໃໝ່ ໃຫ້ຟື້ນຟູເຊສຊັນນຳ

ຟັງຊັນເອີ້ນກັບຂອງການເຊື່ອມຕໍ່ຄືນໃໝ່ເຮັດວຽກ ແລະ ຊັອກເກັດໃໝ່ເປີດຂຶ້ນ. ນັ້ນແມ່ນການຟື້ນຟູຊັ້ນຂົນສົ່ງ. ມັນບໍ່ໄດ້ໝາຍຄວາມວ່າການສະໝັກ, ການຍອມຮັບຂໍ້ຄວາມ ຫຼື ເຊສຊັນຂອງແອັບຯຂອງເຈົ້າໄດ້ສືບຕໍ່ຈາກຈຸດທີ່ການເຊື່ອມຕໍ່ກ່ອນໜ້າຢຸດໄປ.

ແມ່ນແຕ່ຈຸດປາຍທາງພຣັອກຊີດຽວກັນກໍອາດສ້າງການເຊື່ອມຕໍ່ອອກໃໝ່ໄດ້. ການປ່ຽນ IP ທາງອອກກໍອາດເປີດໃຊ້ນະໂຍບາຍເຊສຊັນຂອງປາຍທາງເອງໄດ້. ຖືວ່າຊັອກເກັດໃໝ່ເປັນການເຊື່ອມຕໍ່ໃໝ່ ແລະ ປະຕິບັດຕາມການແລກປ່ຽນການຟື້ນຟູທີ່ເອກະສານຂອງແອັບຯກຳນົດໄວ້. ຕັດສິນວ່າ ຂະບວນວຽກຄວນຮັກສາເສັ້ນທາງພຣັອກຊີຂອງຕົນ ຫຼືບໍ່ ເມື່ອເຊື່ອມຕໍ່ຄືນໃໝ່.

ເກັບຮັກສາໃຫ້ຫຼາຍກວ່າ URL ສຸດທ້າຍໜ້ອຍໜຶ່ງ

ສະຖານະການຟື້ນຟູທີ່ເປັນປະໂຫຍດອາດປະກອບມີຕົວຕົນເຊສຊັນທີ່ໄດ້ຮັບອະນຸຍາດ, ການສະໝັກທີ່ຕ້ອງການ, ຕົວລະບຸເຫດການສຸດທ້າຍທີ່ຢືນຢັນແລ້ວ ແລະ ການດຳເນີນງານທີ່ຍັງລໍຖ້າການຍອມຮັບ. ຊ່ອງເຫຼົ່ານັ້ນເປັນຂອງໂປຣໂຕຄອນແອັບຯ; WebSocket ບໍ່ໄດ້ກຳນົດໂທເຄັນສືບຕໍ່ສາກົນ.

ຕັດສິນວ່າຈະສືບຕໍ່ຈາກເຄີເຊີ, ເອົາsnapshotໃໝ່ ຫຼື ຍອມຮັບຊ່ອງຫວ່າງ. ຖ້າແຫຼ່ງເຫດການບໍ່ມີອິນເຕີເຟສສຳລັບຫຼິ້ນຄືນ, ການເຊື່ອມຕໍ່ຄືນໄວກວ່າບໍ່ສາມາດພິສູດວ່າບໍ່ມີຂໍ້ຄວາມໃດຕົກຫາຍ.

ສົ່ງສອງເທື່ອອາດໝາຍເຖິງເຮັດສອງເທື່ອ

ຂໍ້ຄວາມທີ່ຖືກໃສ່ຄິວໃນເຄື່ອງກ່ອນການຕັດການເຊື່ອມຕໍ່ອາດບໍ່ເຄີຍອອກຈາກໄຄລເອັນ. ອີກອັນໜຶ່ງອາດໄປຮອດເຊີບເວີໃນຂະນະທີ່ການຍອມຮັບຂອງມັນຫາຍໄປ. ການສົ່ງຄຳສັ່ງທີ່ຍັງບໍ່ໄດ້ຢືນຢັນທຸກອັນຄືນຢ່າງບໍ່ສົນໃຈ ຖືສອງກໍລະນີນີ້ຄືກັນ.

ໃຊ້ຕົວລະບຸຄຳຮ້ອງຂອງບໍລິການ, ການຮອງຮັບ idempotency ຫຼື ກົນໄກປອງດອງກັນບ່ອນທີ່ມີ. ການເຊື່ອມຕໍ່ຊັ້ນຂົນສົ່ງຄືນໃໝ່ບໍ່ສາມາດເຮັດໃຫ້ການກະທຳຂອງແອັບຯກັບຄືນໄດ້ ຫຼື ລຶບຄວາມຊ້ຳຊ້ອນຂອງມັນອັດຕະໂນມັດໄດ້.

ຮັກສາການພະຍາຍາມເຊື່ອມຕໍ່ຄືນໃຫ້ມີຂອບເຂດ ແລະ ຈັງຫວະຕາມນະໂຍບາຍຂອງແອັບຯ. RFC 6455 ແນະນຳໃຫ້ຖອຍຫຼັງຫຼັງການປິດທີ່ຜິດປົກກະຕິ; ກຸ່ມໄຄລເອັນທີ່ພະຍາຍາມຄືນທັນທີອາດເພີ່ມພາລະຂອງການຂັດຂ້ອງ.

ບັນທຶກວ່າແຕ່ລະຄັ້ງເລືອກເສັ້ນທາງພຣັອກຊີໃດ, ແຕ່ໃຫ້ແຍກການຟື້ນຟູເສັ້ນທາງອອກຈາກການຟື້ນຟູແອັບຯ. “ເຊື່ອມຕໍ່ໄດ້ອີກ” ເປັນຫຼັກຖານທີ່ເປັນປະໂຫຍດ. “ຕາມທັນແລ້ວ ແລະ ພ້ອມສົ່ງວຽກເພີ່ມ” ຕ້ອງການການແລກປ່ຽນແອັບຯເພີ່ມເຕີມທີ່ຢືນຢັນເລື່ອງນັ້ນ.