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

ລອງພິຈາລະນາລູກຄ້າທີ່ສົ່ງຄຳຮ້ອງ, ປິດຝັ່ງສົ່ງຂອງຕົນ ແລະ ລໍຖ້າຄຳຕອບ:

client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service

ພຣອກຊີມີສອງການເຊື່ອມຕໍ່ TCP ແລະ ສອງສະຕຣີມໄບຕ໌ທີ່ເຄື່ອນທີ່ຢ່າງເປັນເອກະລາດ. ມັນຕ້ອງສົ່ງຕໍ່ສັນຍານສິ້ນສຸດຂອງອິນພຸດໄປຂ້າງໜ້າ ຫຼັງຈາກສົ່ງໄບຕ໌ທີ່ມາກ່ອນໜ້າມັນແລ້ວ.

ລະບາຍຄິວກ່ອນສົ່ງ EOF

ໃນການຮັບທີ່ມີຂະໜາດບໍ່ແມ່ນສູນເທິງສະຕຣີມ TCP, ການຕອບກັບສູນຊີ້ບອກການສິ້ນສຸດຢ່າງເປັນລະບຽບຂອງສະຕຣີມຂາເຂົ້ານັ້ນ. ໝາຍທິດການອ່ານນັ້ນວ່າສຳເລັດແລ້ວ. ຢຸດລໍຖ້າອິນພຸດເພີ່ມເຕີມຈາກມັນ, ແຕ່ຮັກສາໄບຕ໌ທີ່ເຂົ້າຄິວໄປແລ້ວສຳລັບຊອກເກັດກົງກັນຂ້າມ.

ເມື່ອຄິວຈາກລູກຄ້າໄປຫາບໍລິການຖືກລະບາຍແລ້ວ, ໃຫ້ເອີ້ນ shutdown(service_socket, SHUT_WR) ເທິງຊອກເກັດ POSIX. ມັນຢຸດການສົ່ງຕໍ່ໄປຫາບໍລິການ ໃນຂະນະທີ່ທິດຈາກບໍລິການຫາລູກຄ້າຍັງມີຢູ່. ເມື່ອບໍລິການສຳເລັດຄຳຕອບຂອງມັນ, ໃຫ້ໃຊ້ການດຳເນີນການສະທ້ອນຫຼັງຈາກລະບາຍຄິວຄຳຕອບ.

ການປິດຕົວພັນລະບຸຢູ່ຈຸດທີ່ທັງສອງທິດ ແລະ ບັຟເຟີທີ່ຍັງລໍຖ້າຂອງພວກມັນສຳເລັດແລ້ວ, ຫຼື ຈຸດທີ່ຄວາມຜິດພາດ ຫຼື ການຍົກເລີກຕ້ອງການຢຸດ. ຮັກສາເວລາກຳນົດທີ່ມີຂອບເຂດສຳລັບຄູ່ທີ່ບໍ່ເຄີຍສຳເລັດເຄິ່ງທີ່ເຫຼືອຂອງມັນ.

ຄວາມພ້ອມແມ່ນການເຊີນໃຫ້ອ່ານ

ຊອກເກັດທີ່ອ່ານໄດ້ອາດມີຂໍ້ມູນ ຫຼື ສະພາບ EOF. ເອີ້ນ recv ແລະ ຕີຄວາມໝາຍຜົນຂອງມັນ. ຈຳນວນບວກແມ່ນໄບຕ໌ທີ່ຈະສົ່ງຕໍ່; ສູນແມ່ນຈຸດສິ້ນສຸດຂອງທິດ. ເທິງຊອກເກັດທີ່ບໍ່ບລັອກ, EAGAIN ຫຼື EWOULDBLOCK ໝາຍຄວາມວ່າຕອນນີ້ບໍ່ມີອິນພຸດເພີ່ມເຕີມ, ໃນຂະນະທີ່ EINTR ອາດຕ້ອງລອງໃໝ່. ທັງສອງບໍ່ແມ່ນເຫດການດຽວກັນກັບ EOF.

ຢ່າຊອກຫາທຸງ FIN ໃນບັຟເຟີໄບຕ໌ທີ່ຖືກສົ່ງຄືນ. TCP ສົ່ງສະຕຣີມໄບຕ໌ຕາມລຳດັບໃຫ້ API ນີ້; ຂອບເຂດແພັກເກັດ ແລະ ພາກສ່ວນ FIN ບໍ່ແມ່ນຂໍ້ມູນບັນທຸກຂອງແອັບພລິເຄຊັນປົກກະຕິ.

ນີ້ແມ່ນວົງຈອນຊີວິດຂອງອຸໂມງໄບຕ໌ດິບ. ພຣອກຊີ HTTP ທີ່ແຍກຂໍ້ຄວາມຍັງຕ້ອງເຄົາລົບການສ້າງກອບ HTTP, ແລະ ພຣອກຊີທີ່ສິ້ນສຸດ TLS ກໍມີໂປຣໂຕຄອນປິດ TLS ເຊັ່ນກັນ. ຮັກສາການຕັດສິນໃຈໂປຣໂຕຄອນເຫຼົ່ານັ້ນໄວ້ເໜືອເຣເລ TCP ຕາມທິດ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ