NACK กับ ACK? เมื่อใดควรใช้อีกอันหนึ่ง

โดยส่วนตัวฉันไม่รู้สึกว่าจำเป็นต้องใช้ ACK มันเร็วกว่าถ้าเราแค่ส่ง NACK (n) สำหรับแพ็กเก็ตที่หายไปแทนที่จะส่ง ACK สำหรับแต่ละแพ็กเก็ตที่ได้รับ ดังนั้นเมื่อใด / สถานการณ์ใดที่เราจะใช้ ACK ผ่าน NACK และ viceversa

เหตุผลสำหรับ ACK คือ NACK นั้นไม่เพียงพอ สมมติว่าฉันส่งกระแสข้อมูลของเซ็กเมนต์ X (สมมุติว่า 10 เพื่อความง่าย)

คุณกำลังเชื่อมต่อที่ไม่ดีและรับเซ็กเมนต์ 1, 2, 4 และ 5 เท่านั้นคอมพิวเตอร์ของคุณส่ง NACK สำหรับเซ็กเมนต์ 3 แต่ไม่ทราบว่าควรมีเซ็กเมนต์ 6-10 และไม่ได้ NACK เหล่านั้น

ดังนั้นฉันจึงส่งเซกเมนต์ 3 อีกครั้ง แต่คอมพิวเตอร์ของฉันเชื่อว่าข้อมูลถูกส่งไปอย่างไม่ถูกต้อง

ACK ให้การรับรองว่ากลุ่มมาถึงปลายทางแล้ว

หากคุณต้องการให้แอปพลิเคชันจัดการกับลำดับของข้อมูลและการส่งสัญญาณใหม่คุณสามารถเลือกใช้โปรโตคอลเช่น UDP (ตัวอย่างเช่น TFTP ทำ)

ทุกอย่างจะลดลงไปสู่การกระจายความน่าจะเป็นที่สูญเสียและรูปแบบการรับส่งข้อมูล

ยกตัวอย่างเช่นลิงค์ไร้สายทั่วไปที่มีอัตราการสูญเสีย 10-30% ที่มั่นคง หากคุณรับแต่ละเฟรมที่ได้รับ (เช่น 802.11abg) คุณจะตรวจพบได้อย่างรวดเร็วเมื่อเฟรมหายไปดังนั้นคุณจะไม่เสียเวลาในการรอการหมดเวลา

หากคุณไปที่ NAK แทนคุณจะขึ้นอยู่กับรูปแบบการรับส่งข้อมูล: - หากคุณส่งแพ็กเก็ตคำขอเดียวและคาดว่าจะได้คำตอบและคำขอนั้นหายไปคุณจะต้องหมดเวลาที่จะหมดอายุหากคุณไม่ได้รับ ตอบ. - หากคุณเพียงแค่ส่งกระแสข้อมูลแพ็คเก็ตไปยังผู้รับปิดเสียงส่วนใหญ่ก็เป็นที่ยอมรับได้เพียงรับ NAK เมื่อผู้รับได้รับแพ็คเก็ตต่อไปหรือดังนั้น แต่นี่หมายความว่าผู้รับต้องเรียงลำดับแพ็กเก็ตใหม่และผู้ส่งต้องติดตามงานค้างจำนวนมากของข้อความที่ส่งไป

(เดาว่าโซลูชันใดที่ 802.11n เลือกได้ทั้งสองอย่างผู้รับจะส่งบิตแมปความยาวผันแปรของเฟรมที่ได้รับ)

ตอนนี้ใช้เครือข่ายอินเทอร์เน็ตทั่วไป: คุณมีการสูญเสียแพ็กเก็ตเกือบ 0% จนกระทั่งสิ่งเลวร้ายเกิดขึ้นและคุณมีการสูญเสียแพ็กเก็ตเกือบ 100% ในช่วงเวลาหนึ่งตามกฎหมายการกระจายแบบเลขชี้กำลังจากการขัดจังหวะ 200ms ถึงนาทีและ ครึ่ง.

การรับแพ็คเก็ตแต่ละครั้งดูเหมือนจะไม่มีจุดหมายในเครือข่ายที่ไม่มีการสูญเสียจนกว่าคุณจะพิจารณากรณีที่มีการเชื่อมโยง: คุณจะไม่ได้รับ ACK หรือ NACK เป็นเวลานานและผู้รับจะไม่ส่งอะไรจนกว่าลิงก์ คืนค่าแล้ว

หากคุณใช้ ACK ผู้ส่งจะหยุดส่งและเก็บ backlog ไว้จนกว่าลิงก์จะถูกกู้คืน หากคุณใช้ NACK แทนในที่สุดผู้รับอาจบอกคุณว่าไม่ได้รับแพ็กเก็ตที่หลุดจาก Backlog ของผู้ส่งมาเป็นเวลานานและการเชื่อมต่อนั้นไม่สามารถกู้คืนได้

ACKs มีประโยชน์ในการเลื่อนโพรโทคอลหน้าต่างแบบเลื่อนพวกเขาอนุญาตให้ตัวส่งสัญญาณ A ทราบว่าข้อมูลที่ส่งได้รับจากระยะไกล B. ตัวส่งสัญญาณ A สามารถดำเนินการส่งข้อมูลถัดไปได้ - จนกระทั่งหน้าต่างการส่งข้อมูลนั้นเต็ม ได้รับการยอมรับ)

ACK อาจถูกพิจารณาว่ามีความสำคัญมากกว่า NAKs NAKs อนุญาตให้กู้คืนได้เร็วขึ้นในกรณีที่ไม่ได้รับแพ็กเก็ต / บล็อกที่ส่งโดย A และ B ตรวจพบโดยวิธีที่แพ็กเก็ต / บล็อกหายไป

มันเป็นไปได้อย่างสมบูรณ์แบบในการออกแบบโปรโตคอลที่สนับสนุนการถ่ายโอนและการควบคุมการไหลที่เชื่อถือได้เฉพาะกับ ACK โดยไม่มี NAK (ด้วยการส่งสัญญาณซ้ำโดยเครื่องส่งสัญญาณในกรณีที่เครื่องส่งสัญญาณไม่ได้รับ ACK กลไกการส่งสัญญาณที่จำเป็น

สิ่งหนึ่งที่สำคัญที่สุดที่ฉันต้องการเพิ่มที่นี่ใน TCP เราไม่ได้ส่ง ACK สำหรับแพ็กเก็ตที่ได้รับทุกครั้ง

อย่างไรก็ตาม ACKs จะถูกส่งสำหรับแพ็กเก็ต LAST RECEIVED เท่านั้น

โปรดแก้ไขฉันหากฉันผิด