ເປັນຫຍັງ struct C ຈຶ່ງສາມາດສ້າງຄຳຮ້ອງ SOCKS ທີ່ບໍ່ດີ
ກວດເບິ່ງຄວາມກວ້າງຂອງຟິວທີ່ຊັດເຈນ ລຳດັບໄບຕ໌ ແລະ I/O ແບບສະຕຣີມ ແທນທີ່ຈະຖືວ່າການຈັດວາງຂອງຄອມໄພເລີເປັນຮູບແບບເຄືອຂ່າຍ.
ທີ່ຢູ່ພຣັອກຊີທີ່ຖືກຕ້ອງບໍ່ໄດ້ເຮັດໃຫ້ຂໍ້ຄວາມ SOCKS ທີ່ຂຽນດ້ວຍມືຖືກຕ້ອງ. ການສົ່ງ struct C ຫຼື C++ ອາດສົ່ງການເຕີມຊ່ອງ ຫຼື ຈຳນວນເຕັມຕາມລຳດັບເຄື່ອງ ທີ່ໂປຣໂຕຄອນບໍ່ເຄີຍຮ້ອງຂໍ.
ສຳລັບຄຳຮ້ອງ SOCKS5 CONNECT ທີ່ມີຊື່ໂດເມນ ໃຫ້ເຮັດລຳດັບຕໍ່ໄປນີ້ໃຫ້ຊັດເຈນຫຼັງການເຈລະຈາວິທີ ແລະ ການຢືນຢັນຕົວຕົນທີ່ເລືອກ:
- ເວີຊັນ ຄຳສັ່ງ ໄບຕ໌ສຳຮອງ ແລະ ປະເພດທີ່ຢູ່
- ຄວາມຍາວໂດເມນ ແລະ ໄບຕ໌ໂດເມນ
- ພອດປາຍທາງສອງໄບຕ໌ໃນລຳດັບໄບຕ໌ເຄືອຂ່າຍ
ຄວາມຍາວຂອງທີ່ຢູ່ຂຶ້ນກັບເວີຊັນ SOCKS ແລະ ປະເພດທີ່ຢູ່. ຟິວຕົວເລກຄວາມກວ້າງຄົງທີ່ຕ້ອງການການສະແດງທີ່ກຳນົດໄວ້; ສະຕຣິງໂດເມນມີການເຂົ້າລະຫັດຄວາມຍາວຂອງຕົນເອງ. ຕົວສິ້ນສຸດສະຕຣິງ C ບໍ່ແມ່ນຄຳແນະນຳທົ່ວໄປໃຫ້ເພີ່ມສູນໃສ່ຂໍ້ຄວາມເຄືອຂ່າຍ.
| ທາງລັດໃນການຈັດຕັ້ງ | ບັນຫາທີ່ຕ້ອງກວດ |
|---|---|
| ກຳນົດຄ່າ 32 ບິດຜ່ານພອຍເຕີ 8 ບິດ | ມັນບໍ່ສົ່ງອອກທັງສີ່ໄບຕ໌ |
| ແປງບັຟເຟີເປັນພອຍເຕີຈຳນວນເຕັມທີ່ໃຫຍ່ກວ່າ | ການຈັດລຽງ ແລະ ລຳດັບໄບຕ໌ຍັງຕ້ອງຈັດການ |
| ສົມມຸດວ່າການອ່ານ ຫຼື ຂຽນໜຶ່ງຄັ້ງແມ່ນໜຶ່ງຂໍ້ຄວາມ | TCP ສາມາດສົ່ງໄດ້ພຽງບາງສ່ວນຂອງລຳດັບໂປຣໂຕຄອນ |
ປຽບທຽບແຕ່ລະຟິວກັບປາຍທາງທີ່ຕັ້ງໃຈ ແລະ ຈັດການ I/O ບາງສ່ວນ. ການໄດ້ຮັບສອງໄບຕ໌ບໍ່ໄດ້ພິສູດວ່າຄຳຕອບທັງໝົດມາຮອດແລ້ວ. ການກວດເບິ່ງຂອບເຫຼົ່ານັ້ນສາມາດແຍກຄຳຮ້ອງທີ່ຜິດຮູບແບບອອກຈາກເຊີບເວີທີ່ປະຕິເສດການເຊື່ອມຕໍ່ທີ່ອະທິບາຍຖືກຕ້ອງ.