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

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

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 รายการต่อการอัปโหลดเท่านั้น

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

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

หากต้องการใช้การอัปโหลดหลายส่วน ให้ส่งคำขอ POST ไปยัง URI /upload/package และตั้งค่า 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 ไปยัง URI /upload/package และตั้งค่า 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 เมื่อกลับมาดำเนินการตามคำขออีกครั้งหรือลองอัปโหลดอีกครั้ง ข้อผิดพลาดเหล่านี้อาจเกิดขึ้นหากเซิร์ฟเวอร์ทำงานหนักเกินไป Backoff แบบทวีคูณช่วยลดปัญหาเหล่านี้ได้ในระหว่างที่ได้รับคำขอจำนวนมากหรือมีการใช้งานเครือข่ายปริมาณมาก
  • คำขอประเภทอื่นๆ ไม่ควรจัดการโดย Exponential Backoff แต่คุณก็สามารถลองอีกครั้งได้หลายรายการ เมื่อลองส่งคำขอเหล่านี้อีกครั้ง ให้จำกัดจำนวนครั้งในการส่งคำขออีกครั้ง ตัวอย่างเช่น โค้ดอาจจำกัดการลองใหม่ได้ไม่เกิน 10 ครั้งก่อนที่จะรายงานข้อผิดพลาด
  • จัดการข้อผิดพลาด 404 Not Found รายการเมื่อทำการอัปโหลดต่อโดยการเริ่มการอัปโหลดใหม่ตั้งแต่ต้น

Exponential Backoff

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

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

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

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

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

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

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