สร้างแพ็กเกจ

ตัวเลือกการอัปโหลด

Android Over The Air API ช่วยให้คุณอัปโหลดข้อมูลแพ็กเกจเพื่อสร้างทรัพยากรแพ็กเกจใหม่ได้ สิ่งเหล่านี้คือ แพ็กเกจ OTA ที่สามารถเชื่อมโยงกับการกำหนดค่าอย่างน้อย 1 รายการเพื่อให้ระบบนำส่งการอัปเดตได้ ให้กับอุปกรณ์

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

Linux

ดาวน์โหลดไคลเอ็นต์เครื่องมืออัปโหลด Android Over The Air API v1 สำหรับ Linux

Windows

ดาวน์โหลดไคลเอ็นต์ตัวอัปโหลด Android Over The Air API v1 สำหรับ Windows

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

โปรโตคอลการอัปโหลด

คุณส่งคำขออัปโหลดด้วยวิธีใดก็ได้ต่อไปนี้ ระบุวิธีการที่คุณใช้กับส่วนหัวของคำขอ X-Goog-Upload-Protocol

  • การอัปโหลดหลายส่วน: X-Goog-Upload-Protocol: multipart สำหรับการโอนอย่างรวดเร็ว ไฟล์และข้อมูลเมตาที่เล็กลง จะโอนไฟล์พร้อมกับข้อมูลเมตาที่อธิบาย ทั้งหมดนี้ในคำขอเดียว
  • การอัปโหลดที่ดำเนินการต่อได้: X-Goog-Upload-Protocol: resumable เพื่อการโอนที่เชื่อถือได้ โดยเฉพาะเมื่อใช้ร่วมกับไฟล์ขนาดใหญ่ ด้วยวิธีการนี้ คุณจะใช้คำขอเริ่มต้นเซสชัน ซึ่งอาจรวมข้อมูลเมตาไว้ด้วยก็ได้ กลยุทธ์นี้เป็นกลยุทธ์ที่ดีที่ควรใช้กับผู้ใช้ส่วนใหญ่ เพราะวิธีนี้ยังใช้ได้กับไฟล์ขนาดเล็กที่ต้องเสียค่าคำขอ HTTP เพิ่มเติม 1 คำขอต่อการอัปโหลด 1 ครั้ง

การอัปโหลดหลายส่วน

ตัวเลือกนี้เหมาะสำหรับกรณีที่ข้อมูลที่คุณส่งมีขนาดเล็ก ให้อัปโหลดอีกครั้งได้หากการเชื่อมต่อล้มเหลว

หากต้องการใช้การอัปโหลดหลายส่วน ให้ส่งคำขอ POST ไปยัง /upload/package URI และตั้งค่า X-Goog-Upload-Protocol เป็น multipart

ส่วนหัว HTTP ระดับบนสุดที่จะใช้เมื่อส่งคำขออัปโหลดที่มีหลายส่วนมีดังนี้

  • Content-Type ตั้งค่าเป็น "หลายส่วน/เกี่ยวข้อง" และรวมสตริงขอบเขตที่คุณ ใช้เพื่อระบุส่วนของคำขอ
  • Content-Length ตั้งค่าเป็นจำนวนไบต์ทั้งหมดในเนื้อความของคำขอ

เนื้อหาของคำขอมีการจัดรูปแบบเป็นเนื้อหาmultipart/related ประเภท [RFC2387] และมี 2 ส่วนเท่านั้น ส่วนต่างๆ จะระบุด้วยสตริงขอบเขต และตามด้วยขีดกลาง 2 ตัวตามด้วยสตริงขอบเขตสุดท้าย

แต่ละส่วนของคำขอที่มีหลายส่วนต้องมีส่วนหัว Content-Type เพิ่มเติม:

  1. ส่วนข้อมูลเมตา: ต้องมาก่อนและ Content-Type ต้องเป็น application/json
  2. ส่วนสื่อ: ต้องมาก่อนลำดับที่ 2 และ Content-Type ต้องเป็น application/zip

ตัวอย่าง: การอัปโหลดหลายส่วน

ตัวอย่างด้านล่างแสดงคำขออัปโหลดที่มีหลายส่วนสำหรับ Android Over The Air API

POST /upload/package HTTP/1.1
Host: androidovertheair.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=BOUNDARY
Content-Length: number_of_bytes_in_entire_request_body

--BOUNDARY
Content-Type: application/json; charset=UTF-8

{"deployment": "id", "package_title": "title" }
--BOUNDARY
Content-Type: application/zip; charset=UTF-8

Package ZIP
--BOUNDARY--

หากคำขอสำเร็จ เซิร์ฟเวอร์จะส่งคืนรหัสสถานะ HTTP 200 OK

HTTP/1.1 200

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

ตัวอย่างคำขอ curl 
    JSON={"deployment": "id", "package_title": "title" }
    SERVICE_KEY_FILE=path to your service key json file
    curl \
    -H "$(./oauth2l header --json $SERVICE_KEY_FILE android_partner_over_the_air)" \
    -H "Host: androidovertheair.googleapis.com" \
    -H "X-Goog-Upload-Protocol: multipart" \
    -H "Content-Type: multipart/form-data" \
    -F "json=$JSON;type=application/json" \
    -F "data=@update.zip;type=application/zip" \
    androidovertheair.googleapis.com/upload/package

อัปโหลดต่อได้

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

โปรโตคอลการอัปโหลดที่ดำเนินการต่อได้โดยใช้คำสั่งหลายคำสั่ง ดังนี้

  1. เริ่มเซสชันที่กลับมาทำงานต่อได้ ส่งคำขอเริ่มต้นไปยัง URI การอัปโหลดที่มีเมธอด ข้อมูลเมตา แล้วกำหนดตำแหน่งการอัปโหลดที่ดำเนินการต่อได้ไม่ซ้ำกัน
  2. บันทึก URI ของเซสชันที่เรียกใช้ต่อได้ บันทึก URI ของเซสชันที่แสดงผลใน การตอบกลับคำขอเริ่มต้น เพราะคุณจะใช้สำหรับคำขอที่เหลือในเซสชันนี้
  3. อัปโหลดไฟล์ ส่งไฟล์ ZIP ทั้งหมดหรือบางส่วนไปยัง URI เซสชันที่ดำเนินการต่อได้

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

หมายเหตุ: URI การอัปโหลดจะหมดอายุหลังจากผ่านไป 3 วัน

ขั้นตอนที่ 1: เริ่มเซสชันที่กลับมาทำงานต่อได้

หากต้องการเริ่มการอัปโหลดที่ดำเนินการต่อได้ โปรดส่งคำขอ POST ไปยัง /upload/package URI และตั้งค่า X-Goog-Upload-Protocol เป็น resumable

สำหรับคำขอเริ่มต้นนี้ เนื้อหาต้องมีข้อมูลเมตาเท่านั้น คุณจะโอนหมายเลข เนื้อหาในไฟล์ที่ต้องการอัปโหลดในคำขอต่อๆ มา

ใช้ส่วนหัว HTTP ต่อไปนี้กับคำขอเริ่มต้น

  • X-Goog-Upload-Header-Content-Type นี่คือประเภทเนื้อหาของไฟล์ที่จะอัปโหลดและต้องตั้งค่าเป็น application/zip
  • X-Goog-Upload-Command ตั้งค่าเป็น start
  • X-Goog-Upload-Header-Content-Length กำหนดจำนวนไบต์ของข้อมูลการอัปโหลดที่จะโอนในคำขอที่ตามมา หากไม่ทราบความยาว ณ เวลาที่ส่งคำขอนี้ ก็ละเว้นส่วนหัวนี้ได้
  • Content-Type นี่คือประเภทเนื้อหาของข้อมูลเมตาและต้องตั้งค่าเป็น application/json
  • Content-Length กำหนดเป็นจำนวนไบต์ที่ให้ไว้ในส่วนเนื้อหาของคำขอเริ่มต้นนี้
ตัวอย่าง: คำขอเริ่มเซสชันที่ดำเนินการต่อได้

ตัวอย่างต่อไปนี้แสดงวิธีเริ่มต้นเซสชันที่กลับมาทำงานอีกครั้งสำหรับ Android Over The Air API

POST /upload/package HTTP/1.1
Host: android/over-the-air.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Goog-Upload-Command: start
X-Goog-Upload-Header-Content-Type: application/zip
X-Goog-Upload-Header-Content-Length: 2000000

{"deployment": "id", "package_title": "title" }

ส่วนถัดไปจะอธิบายถึงวิธีจัดการคำตอบ

ขั้นตอนที่ 2: บันทึก URI ของเซสชันที่ดำเนินการต่อได้

หากคำขอเริ่มเซสชันสำเร็จ เซิร์ฟเวอร์ API จะตอบสนองด้วยรหัสสถานะ HTTP 200 OK นอกจากนี้ยังมีส่วนหัว X-Goog-Upload-URL ที่ระบุ URI ของเซสชันที่ดำเนินการต่อได้ ส่วนหัว X-Goog-Upload-URL ที่แสดงในตัวอย่างด้านล่างมีพารามิเตอร์การค้นหา upload_id ซึ่งจะมอบรหัสการอัปโหลดที่ไม่ซ้ำกันเพื่อใช้กับเซสชันนี้ การตอบกลับยังมีX-Goog-Upload-Status ซึ่งจะเป็น active หากคำขออัปโหลดถูกต้องและได้รับการยอมรับ สถานะนี้อาจเป็น final หากการอัปโหลดถูกปฏิเสธ

ตัวอย่าง: การตอบกลับการเริ่มต้นเซสชันที่ดำเนินการต่อได้

การตอบกลับคำขอในขั้นตอนที่ 1 มีดังนี้

HTTP/1.1 200 OK
X-Goog-Upload-Status: active
X-Goog-Upload-URL: androidovertheair.googleapis.com/?upload_id=xa298sd_sdlkj2
Content-Length: 0

ค่าของส่วนหัว X-Goog-Upload-URL ดังที่แสดงในคำตอบตัวอย่างด้านบนคือ URI เซสชันที่คุณจะใช้เป็นปลายทาง HTTP สำหรับอัปโหลดไฟล์จริงหรือค้นหาสถานะการอัปโหลด

คัดลอกและบันทึก URI ของเซสชันเพื่อให้ใช้สำหรับคำขอที่ตามมาได้

ขั้นตอนที่ 3: อัปโหลด

หากต้องการอัปโหลดไฟล์ ให้ส่งคำขอ POST ไปยัง URI การอัปโหลดที่คุณได้รับใน ขั้นตอนก่อนหน้า รูปแบบของคำขออัปโหลดคือ

POST session_uri

ส่วนหัว HTTP ที่จะใช้เมื่อส่งคำขออัปโหลดไฟล์ที่กลับมาทำงานต่อได้มีดังนี้

  1. Content-Length ตั้งค่านี้ตามจำนวนไบต์ที่คุณอัปโหลดในคำขอนี้ ซึ่งโดยทั่วไปจะเป็นขนาดไฟล์อัปโหลด
  2. X-Goog-Upload-Command ตั้งค่าเป็น upload และ finalize
  3. X-Goog-Upload-Offset การดำเนินการนี้จะระบุออฟเซ็ตที่ควรเขียนไบต์ โปรดทราบว่าไคลเอ็นต์ จะต้องอัปโหลดไบต์ตามลำดับ
ตัวอย่าง: คำขออัปโหลดไฟล์ที่กลับมาทำงานต่อได้

นี่คือคำขอที่กลับมาทำงานต่อได้เพื่ออัปโหลดไฟล์ ZIP ขนาด 2,000,000 ไบต์ทั้งไฟล์สำหรับตัวอย่างปัจจุบัน

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Protocol: resumable
X-Goog-Upload-Command: upload, finalize
X-Goog-Upload-Offset: 0
Content-Length: 2000000
Content-Type: application/zip

bytes 0-1999999

หากคำขอประสบความสำเร็จ เซิร์ฟเวอร์จะตอบสนองด้วย HTTP 200 Ok

หากคำขออัปโหลดขัดข้อง หรือคุณได้รับ HTTP 503 Service Unavailable หรือ การตอบสนอง 5xx อื่นๆ จากเซิร์ฟเวอร์ ให้ทำตามขั้นตอนที่ระบุไว้ในอัปโหลดที่หยุดชะงักอีกครั้ง

อัปโหลดไฟล์เป็นส่วนๆ

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

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

ดำเนินการอัปโหลดที่หยุดชะงักต่อ

หากคำขออัปโหลดถูกยกเลิกก่อนได้รับการตอบกลับ หรือคุณได้รับ การตอบสนอง HTTP 503 Service Unavailable จากเซิร์ฟเวอร์ คุณต้องทำการอัปโหลดที่ถูกขัดจังหวะอีกครั้ง หากต้องการทำสิ่งต่อไปนี้

  1. สถานะคำขอ ค้นหาสถานะปัจจุบันของการอัปโหลดโดยส่งคำขอไปยัง URI การอัปโหลด โดยตั้งค่า X-Goog-Upload-Command เป็น query

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

  2. รับจำนวนไบต์ที่อัปโหลด ประมวลผลคำตอบจากการค้นหาสถานะ เซิร์ฟเวอร์ใช้ ส่วนหัว X-Goog-Upload-Size-Received ในการตอบกลับเพื่อระบุจำนวนไบต์ที่ได้รับจนถึงตอนนี้
  3. อัปโหลดข้อมูลที่เหลือ สุดท้าย เมื่อคุณทราบแล้วว่าจะดำเนินการตามคำขอต่อที่ไหน ให้ส่ง ข้อมูลที่เหลืออยู่หรือส่วนปัจจุบัน โปรดทราบว่าคุณต้องจัดการข้อมูลที่เหลือแยกเป็นส่วนๆ ในทั้ง 2 กรณี ดังนั้น คุณต้องตั้งค่าส่วนหัว X-Goog-Upload-Offset ให้มีการชดเชยที่เหมาะสมเมื่ออัปโหลดต่อ
ตัวอย่าง: การอัปโหลดที่หยุดชะงักต่อ

1) ขอสถานะการอัปโหลด

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Command: query

ไคลเอ็นต์จะต้องตรวจสอบส่วนหัว X-Goog-Upload-Status ในการตอบกลับ HTTP ของคำสั่งการค้นหา เช่นเดียวกับคำสั่งทั้งหมด หากมีส่วนหัวและค่าไม่ใช่ active แสดงว่าการอัปโหลดสิ้นสุดลงแล้ว

2) ดึงจำนวนไบต์ที่อัปโหลดไว้จากคำตอบ

การตอบกลับของเซิร์ฟเวอร์จะใช้ส่วนหัว X-Goog-Upload-Size-Received เพื่อระบุว่ามี ได้รับไฟล์ 43 ไบต์แรกของไฟล์แล้ว

HTTP/1.1 200 OK
X-Goog-Upload-Status: active
X-Goog-Upload-Size-Received: 42

3) อัปโหลดต่อจากที่หยุดไว้

คำขอต่อไปนี้จะดำเนินการอัปโหลดต่อโดยการส่งไบต์ที่เหลือของไฟล์ โดยเริ่มต้นที่ไบต์ 43

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Command: upload, finalize
Content-Length: 1999957
X-Goog-Upload-Offset: 43

bytes 43-1999999

แนวทางปฏิบัติแนะนำ

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

  • อัปโหลดต่อหรือลองอัปโหลดอีกครั้งที่ไม่สำเร็จเนื่องจากการเชื่อมต่อขัดข้องหรือข้อผิดพลาด 5xx รายการ ซึ่งรวมถึง
    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout
  • ใช้กลยุทธ์ Exponential Backoff หากเกิดข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ 5xx เมื่อกลับมาดำเนินการกับคำขออัปโหลดต่อหรือลองอัปโหลดอีกครั้ง ข้อผิดพลาดเหล่านี้อาจเกิดขึ้นได้หากเซิร์ฟเวอร์ทำงานหนักเกินไป Exponential Backoff ช่วยลดปัญหาเหล่านี้ในช่วงที่มีคำขอเป็นจำนวนมากหรือมีการรับส่งข้อมูลในเครือข่ายปริมาณมาก
  • ส่วนคำขอประเภทอื่นๆ ก็ไม่ควรจัดการด้วย Exponential Backoff แต่คุณยังคงลองส่งคำขอได้อีกหลายรายการได้ เมื่อพยายามส่งคำขอเหล่านี้ซ้ำ ให้จำกัดจำนวนครั้งในการส่งคำขอซ้ำ เช่น รหัสอาจจำกัดการลองใหม่ไม่เกิน 10 ครั้งก่อนที่จะรายงานข้อผิดพลาด
  • จัดการข้อผิดพลาด 404 Not Found รายการเมื่ออัปโหลดที่ดำเนินการต่อได้โดยเริ่มต้นการอัปโหลดทั้งหมดตั้งแต่ต้น

Exponential Backoff

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

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

ขั้นตอนในการใช้งาน Exponential Backoff อย่างง่ายมีดังนี้

  1. ส่งคำขอไปยัง API
  2. ได้รับการตอบกลับ HTTP 503 ซึ่งบ่งชี้ว่าคุณควรลองส่งคำขออีกครั้ง
  3. โปรดรอ 1 วินาที + สุ่มตัวเลข_จำนวนมิลลิวินาที แล้วลองส่งคำขออีกครั้ง
  4. ได้รับการตอบกลับ HTTP 503 ซึ่งบ่งชี้ว่าคุณควรลองส่งคำขออีกครั้ง
  5. โปรดรอ 2 วินาที + สุ่มตัวเลข_จำนวนมิลลิวินาที แล้วลองส่งคำขออีกครั้ง
  6. ได้รับการตอบกลับ HTTP 503 ซึ่งบ่งชี้ว่าคุณควรลองส่งคำขออีกครั้ง
  7. โปรดรอ 4 วินาที + สุ่มตัวเลข_มิลลิวินาที แล้วลองส่งคำขออีกครั้ง
  8. ได้รับการตอบกลับ HTTP 503 ซึ่งบ่งชี้ว่าคุณควรลองส่งคำขออีกครั้ง
  9. โปรดรอ 8 วินาที + สุ่มตัวเลข_จำนวนมิลลิวินาที แล้วลองส่งคำขออีกครั้ง
  10. ได้รับการตอบกลับ HTTP 503 ซึ่งบ่งชี้ว่าคุณควรลองส่งคำขออีกครั้ง
  11. โปรดรอ 16 วินาที + สุ่มตัวเลข_มิลลิวินาที แล้วลองส่งคำขออีกครั้ง
  12. หยุด รายงานหรือบันทึกข้อผิดพลาด

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

หมายเหตุ: การรอจะมีค่าเป็น (2 ^ n) + sample_number_milliseconds โดยที่ n คือจำนวนเต็มที่เพิ่มขึ้นแบบโมโนนิกซึ่งตอนแรกเริ่มเป็น 0 จำนวนเต็ม n จะเพิ่มขึ้น 1 ครั้งต่อการทำซ้ำแต่ละครั้ง (คำขอแต่ละรายการ)

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