แฮนด์เชก SOCKS สำเร็จแล้ว ตอนนี้รีเลย์อ่านจากไคลเอนต์ เขียนไปยังปลายทาง รอการตอบสนองที่สมบูรณ์ แล้วจึงอ่านจากไคลเอนต์อีกครั้ง ลำดับนั้นอาจทำให้แอปพลิเคชันที่ถูกต้องสมบูรณ์ติดขัดได้

เมื่ออุโมงค์ TCP ถูกสร้างขึ้น SOCKS ไม่ได้กำหนดข้อความภายในนั้น ปลายทางอาจส่งก่อนได้ ทั้งสองฝ่ายอาจส่งอย่างเป็นอิสระ ฝ่ายหนึ่งอาจส่งระเบียนสั้น ๆ แล้วรอคำตอบของอีกฝ่าย

ส่งไบต์ ไม่ใช่ธุรกรรมที่เดาเอา

การเรียกการรับจะคืนไบต์ที่มีอยู่ตามแฟล็กและสถานะของซ็อกเก็ต มันไม่ได้บอกรีเลย์ทั่วไปว่า การตอบสนองของแอปพลิเคชันเสร็จสมบูรณ์แล้ว การรอให้บัฟเฟอร์ขนาดใหญ่ตามอำเภอใจเต็มอาจขัดขวางการส่งข้อความเล็ก ๆ ที่คู่ของมันต้องการเพื่อดำเนินการต่อ

ใช้โมเดลการทำงานพร้อมกันที่มีอยู่ของแอปพลิเคชันเพื่อให้บริการทั้งสองทิศทาง: อีเวนต์ลูป I/O แบบอะซิงโครนัส หรือการออกแบบอื่นที่เลือกอย่างตั้งใจ พฤติกรรมที่สำคัญคือความคืบหน้าในทิศทางหนึ่งไม่ต้องอาศัยขอบเขตข้อความที่ประดิษฐ์ขึ้นในอีกทิศทางหนึ่ง

เก็บบัฟเฟอร์ที่รออยู่สองตัวที่มีขอบเขต

ข้อมูลที่อ่านจากไคลเอนต์อาจยังรอไปถึงปลายทาง ในขณะที่ข้อมูลจากปลายทางรอไปถึงไคลเอนต์ ติดตามไบต์ที่รออยู่เหล่านั้นแยกกัน

การส่งอาจเขียนไบต์น้อยกว่าที่ขอไว้ เก็บส่วนที่ยังไม่ได้เขียนไว้ อย่าทิ้งมันหรือเล่นบัฟเฟอร์ทั้งหมดซ้ำ ซ็อกเก็ตที่เขียนไม่ได้ชั่วคราวเป็นเหตุผลให้รออีเวนต์ความพร้อมที่ถูกต้อง ไม่ใช่หมุนวนอย่างต่อเนื่อง

จำกัดบัฟเฟอร์ หากปลายทางช้า การอ่านข้อมูลไคลเอนต์แบบไม่จำกัดต่อไปเพียงย้ายคิวเข้าไปในหน่วยความจำของรีเลย์ แรงดันย้อนกลับหมายถึงการหยุดอ่านชั่วคราวเมื่อบัฟเฟอร์ที่รออยู่ที่เกี่ยวข้องเต็ม และกลับมาอ่านต่อเมื่อการเขียนทำให้มีที่ว่าง

การสิ้นสุดในทิศทางหนึ่งต้องมีนโยบาย

TCP สามารถปิดทิศทางการส่งได้ในขณะที่อีกทิศทางยังมีข้อมูลที่เป็นประโยชน์ ตัดสินใจว่าจะ ส่งต่อสภาวะนั้นหลังไบต์ที่บัฟเฟอร์ไว้หมดไป อย่างไร และแยกการปิดอย่างเป็นระเบียบออกจากข้อผิดพลาดหรือกำหนดเวลา

ไม่มีสิ่งใดในนี้ที่ต้องการให้รีเลย์ถอดรหัสหรือแยกวิเคราะห์เพย์โหลดของแอปพลิเคชัน มันต้องการการจัดการสตรีมที่ถูกต้อง การเพิ่มขนาดบัฟเฟอร์เพียงอย่างเดียวไม่สามารถซ่อมรีเลย์ที่รอผิดฝ่ายหรือสันนิษฐานว่าทุกการอ่านตรงกับหนึ่งคำขอทั้งหมดได้

บทความที่เกี่ยวข้อง