ການໄຫຼແບບສອງທິດທາງ ແລະ ຄວາມກົດດັນຖອຍຫຼັງໃນ SOCKS relay

ການຈັບມື SOCKS ສຳເລັດແລ້ວ. ຕອນນີ້ relay ອ່ານຈາກ client, ຂຽນໄປຫາປາຍທາງ, ລໍຖ້າຄຳຕອບເຕັມ ແລ້ວຈຶ່ງອ່ານຈາກ client ອີກ. ລຳດັບນັ້ນສາມາດເຮັດໃຫ້ແອັບພລິເຄຊັນທີ່ຖືກຕ້ອງສົມບູນຕິດຂັດ.

ເມື່ອອຸໂມງ TCP ຖືກສ້າງແລ້ວ, SOCKS ບໍ່ໄດ້ກຳນົດຂໍ້ຄວາມພາຍໃນນັ້ນ. ປາຍທາງອາດສົ່ງກ່ອນ. ທັງສອງຝ່າຍອາດສົ່ງຢ່າງເປັນເອກະລາດ. ຝ່າຍໜຶ່ງອາດສົ່ງບັນທຶກສັ້ນໆ ແລ້ວລໍຖ້າຄຳຕອບຂອງອີກຝ່າຍ.

ສົ່ງຕໍ່ byte ບໍ່ແມ່ນທຸລະກຳທີ່ເດົາເອົາ

ການເອີ້ນຮັບຄືນຈະສົ່ງ byte ທີ່ມີຢູ່ຕາມ flag ແລະ ສະຖານະຂອງ socket. ມັນບໍ່ໄດ້ບອກ relay ທົ່ວໄປວ່າ ຄຳຕອບຂອງແອັບພລິເຄຊັນສຳເລັດແລ້ວ. ການລໍຖ້າໃຫ້ buffer ໃຫຍ່ຕາມອຳເພີໃຈເຕັມ ອາດຂັດຂວາງການສົ່ງຕໍ່ຂໍ້ຄວາມນ້ອຍໆທີ່ຄູ່ຂອງມັນຕ້ອງການເພື່ອສືບຕໍ່.

ໃຊ້ຮູບແບບການເຮັດວຽກພ້ອມກັນທີ່ມີຢູ່ແລ້ວຂອງແອັບພລິເຄຊັນເພື່ອບໍລິການທັງສອງທິດທາງ: event loop, I/O ແບບ asynchronous ຫຼື ການອອກແບບອື່ນທີ່ເລືອກຢ່າງຕັ້ງໃຈ. ພຶດຕິກຳສຳຄັນແມ່ນຄວາມຄືບໜ້າໃນທິດໜຶ່ງບໍ່ຕ້ອງການຂອບເຂດຂໍ້ຄວາມທີ່ແຕ່ງຂຶ້ນໃນອີກທິດໜຶ່ງ.

ເກັບ buffer ທີ່ລໍຖ້າຢູ່ສອງອັນທີ່ມີຂອບເຂດ

ຂໍ້ມູນທີ່ອ່ານຈາກ client ອາດຍັງລໍຖ້າໄປຮອດປາຍທາງ ໃນຂະນະທີ່ຂໍ້ມູນຈາກປາຍທາງລໍຖ້າໄປຮອດ client. ຕິດຕາມ byte ທີ່ລໍຖ້າເຫຼົ່ານັ້ນແຍກກັນ.

ການສົ່ງອາດຂຽນ byte ໜ້ອຍກວ່າທີ່ຮ້ອງຂໍ. ເກັບສ່ວນທີ່ຍັງບໍ່ໄດ້ຂຽນໄວ້; ຢ່າຖິ້ມມັນ ຫຼື ຫຼິ້ນ buffer ທັງໝົດຄືນ. socket ທີ່ຂຽນບໍ່ໄດ້ຊົ່ວຄາວເປັນເຫດຜົນທີ່ຈະລໍຖ້າ event ຄວາມພ້ອມທີ່ຖືກຕ້ອງ ບໍ່ແມ່ນໝຸນຢ່າງຕໍ່ເນື່ອງ.

ຈຳກັດ buffer. ຖ້າປາຍທາງຊ້າ, ການອ່ານຂໍ້ມູນ client ແບບບໍ່ຈຳກັດຕໍ່ໄປພຽງແຕ່ຍ້າຍຄິວເຂົ້າໄປໃນຫນ່ວຍຄວາມຈຳຂອງ relay. backpressure ໝາຍເຖິງການຢຸດອ່ານຊົ່ວຄາວເມື່ອ buffer ທີ່ລໍຖ້າທີ່ກ່ຽວຂ້ອງເຕັມ ແລະ ການເລີ່ມອ່ານຄືນເມື່ອການຂຽນເຮັດໃຫ້ມີບ່ອນຫວ່າງ.

ການສິ້ນສຸດໃນທິດໜຶ່ງຕ້ອງການນະໂຍບາຍ

TCP ສາມາດປິດທິດການສົ່ງໄດ້ ໃນຂະນະທີ່ອີກທິດໜຶ່ງຍັງມີຂໍ້ມູນທີ່ເປັນປະໂຫຍດ. ຕັດສິນໃຈວ່າຈະ ສົ່ງຕໍ່ສະພາບນັ້ນຫຼັງຈາກ byte ໃນ buffer ໝົດໄປ ແນວໃດ, ແລະ ແຍກການປິດຢ່າງເປັນລະບຽບອອກຈາກຂໍ້ຜິດພາດ ຫຼື ກຳນົດເວລາ.

ບໍ່ມີສິ່ງໃດໃນນີ້ທີ່ຕ້ອງການໃຫ້ relay ຖອດລະຫັດ ຫຼື ແຍກວິເຄາະ payload ຂອງແອັບພລິເຄຊັນ. ມັນຕ້ອງການການຈັດການກະແສທີ່ຖືກຕ້ອງ. ການເພີ່ມຂະໜາດ buffer ຢ່າງດຽວບໍ່ສາມາດແກ້ໄຂ relay ທີ່ລໍຖ້າຜິດຝ່າຍ ຫຼື ສົມມຸດວ່າທຸກການອ່ານກົງກັບໜຶ່ງຄຳຮ້ອງຂໍທັງໝົດ.