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

ฉันกำลังส่งข้อมูลจำนวนมากไปยังเซิร์ฟเวอร์ ตอนนี้ขณะที่ฉันส่งข้อมูลและรอการตอบกลับจากเซิร์ฟเวอร์อุปกรณ์ Android ของฉันก็ขาดการเชื่อมต่ออินเทอร์เน็ต
ดังนั้นสิ่งที่ฉันเคยทำคือการแสดงกล่องโต้ตอบการแจ้งเตือนของการเชื่อมต่อที่หายไป แต่ที่ฝั่งเซิร์ฟเวอร์ข้อมูลได้รับการประมวลผลแล้วและได้รับการอัปเดตที่ใดที่หนึ่งเช่น URL ใด ๆ แต่โทรศัพท์ Android ของฉันไม่รู้สิ่งนี้เพราะมันไม่ได้รับการตอบสนองเลย วิธีแก้ไข
ไม่ว่าจะสามารถทำได้บนฝั่งเซิร์ฟเวอร์หรือบนตัว Android เองได้อย่างไร?
เซิร์ฟเวอร์จะรู้ได้อย่างไรว่าโทรศัพท์ android จะไม่ฟังคำตอบ?
มันอาจเป็นมุมมองการเพิ่มประสิทธิภาพการสื่อสารลูกค้า - เซิร์ฟเวอร์

— mayank_droid
แหล่งที่มา

เราพูดถึงข้อมูลเท่าไหร่? กิกะไบต์?

— Daniel Hollinrake

ไม่มากประมาณ 7-8 MB แต่เวลาตอบสนองของเซิร์ฟเวอร์ยาวเกินไปและอัตราการอัพโหลดจากโทรศัพท์อยู่ที่ประมาณ 128 KB / S ฉันไม่ได้พูดถึงขนาดข้อมูล แต่มีปัญหาการเชื่อมต่อ

— mayank_droid

คำตอบ:

นี่เป็นปัญหาที่พบได้บ่อยในการทำธุรกรรมแบบอะซิงโครนัสและอยู่ในหลายส่วน

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

สิ่งที่ดีเกี่ยวกับ HTTP ก็คือมันค่อนข้างง่ายในการแก้ไขปัญหาเหล่านี้

ลองนึกภาพโครงสร้าง URL ดังนี้:

POST http://my.server.com/application/engine/queue 
GET   http://my.server.com/application/engine/results?jobid=43425

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

ลูกค้าได้รับผลลัพธ์ของคำขอจาก URL ผลลัพธ์ การโทรนี้สามารถทำซ้ำได้บ่อยเท่าที่ต้องการเพื่อให้ได้ผลลัพธ์ หากมีการเรียกก่อนที่ผลลัพธ์จะพร้อมใช้งานการตอบกลับอาจเป็นการตอบกลับแบบไม่มีเนื้อหาเพื่อให้ลูกค้ารู้ว่าเซิร์ฟเวอร์จดจำรหัสงาน แต่ยังไม่มีเนื้อหา หาก ID งานไม่เป็นที่รู้จัก NOT-FOUND คือการตอบสนองที่เหมาะสม

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

— Michael Shaw
แหล่งที่มา

หรือเพียงแค่ขอสั้น ๆ เพื่อขอ ID ธุรกรรมจากนั้นมีหลายคำขอที่เพิ่มข้อมูลไปยังธุรกรรม (คุณสามารถแบ่งการถ่ายโอนเป็นชิ้นเล็ก ๆ ที่นี่เพื่อรับการตอบรับบางส่วน) จากนั้นขอคำขอ "ยอมรับ" ขั้นสุดท้าย จากนั้นคุณสามารถมีการหมดเวลาที่แตกต่างกันสำหรับการทำธุรกรรมที่ว่างเปล่าอย่างสมบูรณ์ (ลูกค้าส่วนใหญ่ไม่ได้รับ ID), การทำธุรกรรมที่อัปโหลดบางส่วนและผลลัพธ์ (หากลูกค้าไม่ได้รับผลลัพธ์ก็อาจลองคำขอ "ส่ง") อีกครั้ง

— Simon Richter

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

— Michael Shaw

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

— Simon Richter

ใช่มันสมเหตุสมผลแล้ว

— Michael Shaw

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

— Simon Richter

สิ่งนี้อยู่ภายใต้พื้นฐานของการสื่อสารโปรโตคอล ธุรกรรมได้รับการร้องขอจากไคลเอนต์ Android และเซิร์ฟเวอร์จะต้องทำธุรกรรม หากการทำธุรกรรมขึ้นอยู่กับการรับรู้ของลูกค้า Android กว่านี้คือการสื่อสาร ACK / NAK โทร

ACK (การตอบรับ) และNAK (การรับรู้เชิงลบ)ใช้เพื่อบอกผลการร้องขออีกด้านหนึ่ง

สิ่งที่คุณถามเกี่ยวกับคือการแลกเปลี่ยนจับมือกันระหว่างลูกค้าและเซิร์ฟเวอร์และสามารถดำเนินการได้ด้วยการแลกเปลี่ยน ACK / NAK พื้นฐาน

นี่คือตัวอย่างของ Android ที่อัปโหลดไฟล์ที่มีการตอบรับสองทาง

Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server

ในตัวอย่างด้านบนฉันได้เพิ่ม#idตัวระบุเฉพาะสำหรับธุรกรรม เซิร์ฟเวอร์ควรได้รับไฟล์สร้างบันทึกการทำธุรกรรมและส่งไปที่การตอบสนองกลับไปที่ Android Android ควรปฏิบัติตามพร้อมกับรับทราบการทำธุรกรรมนั้น (หรืออีกทางหนึ่งคือ NAK สำหรับการปฏิเสธ)

นี่คือตัวอย่างของการตัดการเชื่อมต่อ Android ระหว่างการจับมือกัน

Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/

ในตัวอย่างด้านบนเซิร์ฟเวอร์ยอมรับไฟล์ที่อัพโหลดและส่งการ#idตอบกลับ ACK กลับไปที่ Android แต่ Android ไม่ตอบสนองด้วย ACK อุปกรณ์ Android ล้มเหลวในการจับมือ ขึ้นอยู่กับคุณที่จะตัดสินใจว่าเซิร์ฟเวอร์ควรจัดการกับเรื่องนี้อย่างไร ทำลายธุรกรรมทำธุรกรรมต่อและรอให้อุปกรณ์ Android กลับมาในภายหลังหรือทำธุรกรรมให้เสร็จสิ้น

เซิร์ฟเวอร์สามารถสันนิษฐานได้ว่าเนื่องจากอุปกรณ์ไม่ตอบสนองกับ ACK อุปกรณ์ Android ไม่ได้อัปเดตเป็นสถานะภายในเพื่อระบุว่าการอัปโหลดสำเร็จ ฉันจะยกเลิกการทำธุรกรรมและอนุญาตให้อุปกรณ์ทำซ้ำในอนาคต

— Reactgular
แหล่งที่มา