بارگذاری تصاویر با Play Games Services Publishing API

‫Play Games Services Publishing API به شما اجازه می‌دهد تصویری برای منبع بازی بارگذاری کنید.

گزینه‌های بارگذاری

‫Play Games Services Publishing API به شما اجازه می‌دهد انواع خاصی از داده‌های باینری یا رسانه را بارگذاری کنید. ویژگی‌های خاص داده‌هایی که می‌توانید بارگذاری کنید در صفحه مرجع برای هر روشی که از بارگذاری رسانه پشتیبانی می‌کند مشخص شده است:

• حداکثر اندازه فایل بارگذاری: حداکثر مقدار داده‌ای که می‌توانید با این روش ذخیره کنید.

• انواع MIME رسانه پذیرفته‌شده: انواع داده‌های باینری که می‌توانید بااستفاده از این روش ذخیره کنید.

می‌توانید درخواست‌های بارگذاری را به هریک از روش‌های زیر انجام دهید. روشی را که با پارامتر درخواست uploadType استفاده می‌کنید مشخص کنید.

• بارگذاری ساده: uploadType=media. برای انتقال سریع فایل‌های کوچک‌تر، برای مثال، ۵ مگابایت یا کمتر.

• بارگذاری چندبخشی: uploadType=multipart. برای انتقال سریع فایل‌های کوچک‌تر و فراداده؛ فایل را همراه با فراداده‌ای که آن را توصیف می‌کند، همه در یک درخواست، منتقل می‌کند.

• بارگذاری ازسرگیری‌پذیر: uploadType=resumable. برای انتقال قابل‌اعتماد، به‌ویژه برای فایل‌های بزرگ‌تر مهم است. با این روش، از یک درخواست شروع جلسه استفاده می‌کنید که به‌صورت اختیاری می‌تواند شامل فراداده باشد. این استراتژی برای اکثر برنامه‌ها مناسب است، زیرا برای فایل‌های کوچک‌تر نیز کار می‌کند، هرچند که هزینه آن یک درخواست HTTP اضافی برای هر بارگذاری است.

وقتی رسانه بارگذاری می‌کنید، از یک نشانی وب خاص استفاده می‌کنید. درواقع، روش‌هایی که از بارگذاری رسانه پشتیبانی می‌کنند دو نقطه پایان نشانی وب دارند:

• نشانی وب /upload، برای رسانه. قالب نقطه پایانی بارگذاری، نشانی وب منبع استاندارد با پیشوند «/upload» است. از این نشانی وب هنگام انتقال خود داده‌های رسانه استفاده کنید.

  مثال: POST /upload/games/v1configuration/images/resourceId/imageType/imageType

• نشانی وب منبع استاندارد، برای فراداده. اگر منبع حاوی هرگونه فیلد داده باشد، از آن فیلدها برای ذخیره فراداده‌های توصیف‌کننده فایل بارگذاری‌شده استفاده می‌شود. هنگام ایجاد یا به‌روزرسانی مقادیر فراداده می‌توانید از این نشانی وب استفاده کنید.

  مثال: POST /games/v1configuration/images/resourceId/imageType/imageType

بارگذاری ساده

ساده‌ترین روش برای بارگذاری فایل، ایجاد یک درخواست بارگذاری ساده است. این گزینه زمانی انتخاب خوبی است که یکی از موارد زیر درست باشد:

• اگر اتصال قطع شود، فایل به‌اندازه کافی کوچک است که بتوان آن را به‌طور کامل دوباره بارگذاری کرد.

• فراداده‌ای برای ارسال وجود ندارد. اگر قصد دارید فراداده این منبع را در درخواستی جداگانه ارسال کنید، یا اگر هیچ فراداده‌ای پشتیبانی یا دردسترس نیست، این مورد ممکن است درست باشد. برای استفاده از بارگذاری ساده، یک درخواست POST یا PUT به URI /upload روش ارسال کنید و پارامتر پُرسمان uploadType=media را اضافه کنید. برای مثال:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media

سرصفحه‌های HTTP که هنگام ایجاد درخواست بارگذاری ساده استفاده می‌شوند عبارت‌اند از:

• Content-Type. روی یکی از انواع داده‌های رسانه‌ای بارگذاری پذیرفته‌شده روش تنظیم کنید، که در مرجع «میانای برنامه‌سازی کاربردی انتشار» مشخص شده است.

• Content-Length. روی تعداد بایتی که بارگذاری می‌کنید تنظیم کنید. اگر از کدبندی انتقال تکه‌تکه استفاده می‌کنید، لازم نیست.

مثال: بارگذاری ساده

مثال زیر استفاده از یک درخواست بارگذاری ساده برای Play Games Services Publishing API را نشان می‌دهد.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/png
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

PNG data

اگر درخواست موفقیت‌آمیز باشد، سرور کد وضعیت HTTP 200 OK را همراه با هر فراداده‌ای برمی‌گرداند. برای مثال:

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

بارگذاری چندبخشی

اگر فراداده‌ای دارید که می‌خواهید همراه با داده‌ها برای بارگذاری ارسال کنید، می‌توانید یک درخواست multipart/related ایجاد کنید. اگر داده‌هایی که ارسال می‌کنید به‌اندازه کافی کوچک باشد که درصورت قطع شدن اتصال بتوانید دوباره کل آن را بارگذاری کنید، این گزینه انتخاب خوبی است.

برای استفاده از بارگذاری چندبخشی، یک درخواست POST یا PUT به نشانی وب یکنواخت (URI) روش /upload ایجاد کنید و پارامتر پُرسمان uploadType=multipart را اضافه کنید. برای مثال:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart

سرصفحه‌های اچ‌تی‌تی‌پی سطح بالا برای استفاده هنگام ایجاد درخواست بارگذاری چندبخشی شامل موارد زیر است:

-Content-Type. روی multipart/related تنظیم کنید و رشته مرزی را که برای شناسایی بخش‌های درخواست استفاده می‌کنید اضافه کنید.

-Content-Length. روی تعداد کل بایت‌های متن درخواست تنظیم کنید. بخش رسانه درخواست باید کمتر از حداکثر اندازه فایل مشخص‌شده برای این روش باشد.

بدنه درخواست به‌عنوان نوع محتوای چندبخشی/مرتبط قالب‌بندی شده است RFC2387 و دقیقاً شامل دو بخش است. بخش‌ها با یک رشته مرزی شناسایی می‌شوند، و رشته مرزی نهایی با دو خط تیره دنبال می‌شود.

هر بخش از درخواست چندبخشی به سرایند «نوع محتوای» اضافی نیاز دارد:

• بخش فراداده: باید اول بیاید و «نوع محتوا» باید با یکی از قالب‌های فراداده پذیرفته‌شده مطابقت داشته باشد.

• بخش رسانه: باید دومین بخش باشد و «نوع محتوا» باید با یکی از انواع رسانه MIME پذیرفته‌شده روش مطابقت داشته باشد.

برای فهرست انواع MIME رسانه‌ای پذیرفته‌شده و محدودیت‌های اندازه فایل‌های بارگذاری‌شده برای هر روش، به مرجع API انتشار مراجعه کنید.

مثال: بارگذاری چندبخشی

مثال زیر درخواست بارگذاری چندبخشی برای Play Games Services Publishing API را نشان می‌دهد.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=foo_bar_baz
Content-Length: number_of_bytes_in_entire_request_body

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

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

--foo_bar_baz
Content-Type: image/png

PNG data
--foo_bar_baz--

اگر درخواست موفقیت‌آمیز باشد، سرور کد وضعیت HTTP 200 OK را به‌همراه هرگونه فراداده برمی‌گرداند:

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

بارگذاری ازسرگیری‌پذیر

برای بارگذاری مطمئن‌تر فایل‌های داده، می‌توانید از پروتکل بارگذاری ازسرگیری‌پذیر استفاده کنید. این پروتکل به شما امکان می‌دهد عملیات بارگذاری را پس‌از قطع شدن جریان داده‌ها به‌دلیل خرابی ارتباط ازسر بگیرید. این ویژگی به‌ویژه زمانی مفید است که درحال انتقال فایل‌های بزرگ هستید و احتمال قطع شدن شبکه یا بروز مشکل در انتقال داده‌ها زیاد است، برای مثال، هنگام بارگذاری از برنامه مشتری تلفن همراه. این ویژگی همچنین می‌تواند درصورت بروز مشکل در شبکه، مصرف پهنای باند شما را کاهش دهد زیرا لازم نیست بارگذاری فایل‌های بزرگ را از ابتدا شروع کنید.

مراحل استفاده از بارگذاری ازسرگیری‌پذیر شامل موارد زیر است:

1. جلسه قابل‌ازسرگیری را شروع کنید. درخواست اولیه‌ای به نشانی وب بارگذاری که شامل فراداده است (درصورت وجود) ارسال کنید.

2. نشانی وب جلسه ازسرگیری را ذخیره کنید. نشانی وب جلسه برگشت‌داده‌شده در پاسخ درخواست اولیه را ذخیره کنید؛ از آن برای درخواست‌های باقی‌مانده در این جلسه استفاده خواهید کرد. فایل را بارگذاری کنید.

3. فایل رسانه‌ای را به نشانی وب جلسه ازسرگیری ارسال کنید.

علاوه‌براین، برنامه‌هایی که از بارگذاری ازسرگیری‌شدنی استفاده می‌کنند باید کد ازسرگیری بارگذاری وقفه ایجادشده را داشته باشند. اگر بارگذاری قطع شد، متوجه شوید که چه مقدار داده با موفقیت دریافت شده است، و سپس بارگذاری را از آن نقطه ازسر بگیرید.

شروع جلسه ازسرگیری‌پذیر

برای شروع بارگذاری ازسرگیری‌پذیر، درخواست POST یا PUT به نشانی یکنواخت منبع /upload روش ارسال کنید و پارامتر پُرسمان uploadType=resumable را اضافه کنید. برای مثال:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable

برای این درخواست آغازگر، بدنه یا خالی است یا فقط حاوی فراداده است؛ محتوای واقعی فایلی را که می‌خواهید بارگذاری کنید در درخواست‌های بعدی منتقل خواهید کرد.

از سرصفحه‌های HTTP زیر با درخواست اولیه استفاده کنید:

• X-Upload-Content-Type. روی نوع MIME رسانه داده‌های بارگذاری‌شده تنظیم کنید تا در درخواست‌های بعدی منتقل شود.

• X-Upload-Content-Length. روی تعداد بایت‌های داده بارگذاری تنظیم کنید تا در درخواست‌های بعدی منتقل شود. اگر طول در زمان این درخواست نامشخص است، می‌توانید این سرایند را حذف کنید.

• اگر فراداده ارائه می‌دهید: Content-Type. براساس نوع داده فراداده تنظیم می‌شود.

• ‫Content-Length. روی تعداد بایت‌های ارائه‌شده در متن این درخواست اولیه تنظیم کنید. اگر از chunked transfer encoding استفاده می‌کنید، لازم نیست.

برای فهرست انواع رسانه MIME پذیرفته‌شده و محدودیت‌های اندازه برای فایل‌های بارگذاری‌شده، به مرجع «میانای برنامه‌سازی کاربردی انتشار» برای هر روش مراجعه کنید.

مثال: درخواست شروع جلسه قابل‌ازسرگیری

مثال زیر نحوه شروع جلسه ازسرگیری برای «میانای برنامه‌سازی کاربردی انتشار خدمات بازی‌های Play» را نشان می‌دهد.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Type: image/png
X-Upload-Content-Length: 2000000

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

بخش بعدی نحوه مدیریت پاسخ را شرح می‌دهد.

ذخیره کردن نشانی وب جلسه ازسرگیری‌پذیر

اگر درخواست آغاز جلسه موفق باشد، سرور API با کد وضعیت 200 OK HTTP پاسخ می‌دهد. علاوه‌براین، سرصفحه Location را ارائه می‌دهد که شناسه یکنواخت منبع جلسه ازسرگیری‌شدنی شما را مشخص می‌کند. سرصفحه Location که در مثال زیر نشان داده شده است، شامل بخشی از پارامتر پُرسمان upload_id است که شناسه بارگذاری منحصربه‌فرد را برای استفاده در این جلسه ارائه می‌دهد.

مثال: پاسخ آغاز جلسه قابل‌ازسرگیری

در اینجا پاسخ درخواست در مرحله ۱ آمده است:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

مقدار سرایند Location، همان‌طور که در پاسخ مثال بالا نشان داده شده است، نشانی وب جلسه است که از آن به‌عنوان نقطه پایانی HTTP برای انجام بارگذاری واقعی فایل یا پُرسمان وضعیت بارگذاری استفاده خواهید کرد.

نشانی وب جلسه را کپی و ذخیره کنید تا بتوانید از آن برای درخواست‌های بعدی استفاده کنید.

بارگذاری فایل

برای بارگذاری فایل، درخواست PUT را به نشانی وب بارگذاری که در مرحله قبلی دریافت کردید ارسال کنید. قالب درخواست بارگذاری به این صورت است:

PUT session_uri

سرصفحه‌های HTTP که هنگام ایجاد درخواست‌های بارگذاری فایل ازسرگیری‌پذیر استفاده می‌شوند شامل Content-Length است. این را روی تعداد بایتی که در این درخواست بارگذاری می‌کنید تنظیم کنید، که معمولاً اندازه فایل بارگذاری است.

مثال: درخواست بارگذاری فایل ازسرگیری‌شدنی

در اینجا درخواست ازسرگیری برای بارگذاری کل فایل PNG با حجم ۲٬۰۰۰٬۰۰۰ بایت برای مثال کنونی آورده شده است.

PUT https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: image/png

bytes 0-1999999

اگر درخواست موفقیت‌آمیز باشد، سرور با HTTP 201 Created، به‌همراه هر فراداده مرتبط با این منبع پاسخ می‌دهد. اگر درخواست اولیه جلسه ازسرگیری PUT بوده باشد، برای به‌روزرسانی منبع موجود، پاسخ موفقیت‌آمیز 200 OK خواهد بود، به‌همراه هر فراداده مرتبط با این منبع.

اگر درخواست بارگذاری قطع شد یا اگر HTTP 503 Service Unavailable یا هر پاسخ 5xx دیگری از سرور دریافت کردید، روش ذکرشده در ازسرگیری بارگذاری قطع‌شده را دنبال کنید.

فایل را به‌صورت تکه‌های کوچک بارگذاری کنید

با بارگذاری‌های ازسرگیری‌پذیر، می‌توانید یک فایل را به چند بخش تقسیم کنید و مجموعه‌ای از درخواست‌ها را برای بارگذاری هر بخش به‌ترتیب ارسال کنید. این رویکرد ترجیحی نیست زیرا هزینه‌های عملکردی مرتبط با درخواست‌های اضافی وجود دارد، و به‌طورکلی نیازی به آن نیست. بااین‌حال، ممکن است لازم باشد از تکه‌تکه کردن برای کاهش مقدار داده منتقل‌شده در هر درخواست استفاده کنید. این کار زمانی مفید است که برای درخواست‌های فردی محدودیت زمانی ثابتی وجود داشته باشد، همان‌طور که برای برخی‌از کلاس‌های درخواست‌های Google App Engine صادق است. همچنین به شما امکان می‌دهد کارهایی مانند ارائه نشانگرهای پیشرفت بارگذاری برای مرورگرهای قدیمی که به‌طور پیش‌فرض از پیشرفت بارگذاری پشتیبانی نمی‌کنند را انجام دهید.

اگر داده‌ها را به‌صورت تکه‌ای بارگذاری می‌کنید، سرصفحه «محدوده محتوا» نیز همراه با سرصفحه «طول محتوا» که برای بارگذاری فایل کامل لازم است، الزامی است:

• Content-Length. روی اندازه تکه یا احتمالاً کمتر تنظیم کنید، همان‌طور که ممکن است برای آخرین درخواست این‌گونه باشد.

• Content-Range. تنظیم کنید تا نشان دهد کدام بایت‌ها در فایلی که بارگذاری می‌کنید. برای مثال، Content-Range: bytes 0-524287/2000000 نشان می‌دهد که شما اولین ۵۲۴٬۲۸۸ بایت (۲۵۶ × ۱۰۲۴ × ۲) را در یک فایل ۲٬۰۰۰٬۰۰۰ بایتی ارائه می‌دهید.

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: image/jpeg
Content-Range: bytes 0-524287/2000000

bytes 0-524288

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: bytes=0-524287

ازسرگیری بارگذاری دارای وقفه

اگر درخواست بارگذاری قبل‌از دریافت پاسخ خاتمه یابد یا اگر پاسخ HTTP 503 Service Unavailable از سرور دریافت کنید، باید بارگذاری قطع‌شده را ازسر بگیرید. برای ازسرگیری بارگذاری قطع‌شده، موارد زیر را انجام دهید:

1. وضعیت درخواست. با صدور درخواست PUT خالی به نشانی وب بارگذاری، وضعیت فعلی بارگذاری را پُرسمان کنید. برای این درخواست، سراینده‌های HTTP باید سراینده Content-Range را داشته باشند که نشان دهد موقعیت فعلی در فایل ناشناخته است. برای مثال، اگر طول کل فایل شما ۲٬۰۰۰٬۰۰۰ است، Content-Range را روی */2000000 تنظیم کنید. اگر اندازه کامل فایل را نمی‌دانید، «محدوده محتوا» را روی */* تنظیم کنید.

2. تعداد بایت‌های بارگذاری‌شده را دریافت کنید. پاسخ پرسمان وضعیت را پردازش کنید. سرور از سرصفحه Range در پاسخ خود برای مشخص کردن اینکه تاکنون کدام بایت‌ها را دریافت کرده است استفاده می‌کند. برای مثال، سرایند Range از 0-299999 نشان می‌دهد که ‫۳۰۰٬۰۰۰ بایت اول فایل دریافت شده است.

3. بارگذاری داده‌های باقی‌مانده. درنهایت، اکنون که می‌دانید درخواست را از کجا ازسر بگیرید، داده‌های باقی‌مانده یا تکه فعلی را ارسال کنید. توجه داشته باشید که در هر دو حالت باید داده‌های باقی‌مانده را به‌عنوان تکه جداگانه‌ای درنظر بگیرید، بنابراین وقتی بارگذاری را ازسر می‌گیرید باید سرصفحه Content-Range را ارسال کنید.

مثال: ازسرگیری بارگذاری قطع‌شده

1. وضعیت بارگذاری را درخواست کنید. درخواست زیر از سرصفحه Content-Range استفاده می‌کند تا نشان دهد موقعیت فعلی در فایل ۲٬۰۰۰٬۰۰۰ بایتی نامشخص است.

   PUT {session_uri} HTTP/1.1
   Content-Length: 0
   Content-Range: bytes */2000000
   

2. تعداد بایت‌های بارگذاری‌شده تاکنون را از پاسخ استخراج کنید. پاسخ سرور از سرصفحه Range برای نشان دادن اینکه تاکنون ۴۳ بایت اول فایل را دریافت کرده است استفاده می‌کند. از مقدار بالایی سرصفحه «محدوده» برای تعیین محل شروع بارگذاری ازسرگرفته‌شده استفاده کنید.

   HTTP/1.1 308 Resume Incomplete
   Content-Length: 0
   Range: 0-42
   

3. بارگذاری را از جایی که متوقف شده است ازسر بگیرید. درخواست زیر بارگذاری را با ارسال بایت‌های باقی‌مانده فایل، از بایت ۴۳ شروع می‌کند.

   PUT {session_uri} HTTP/1.1
   Content-Length: 1999957
   Content-Range: bytes 43-1999999/2000000
   
   bytes 43-1999999
   

مدیریت کردن خطا

هنگام بارگذاری رسانه، بهتر است با برخی‌از روال‌های مطلوب مربوط به مدیریت خطا آشنا باشید.

• بارگذاری‌هایی را که به‌دلیل قطع اتصال یا هرگونه خطای 5xx ناموفق بوده‌اند ازسر بگیرید یا دوباره امتحان کنید، ازجمله:

  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

• اگر هنگام ازسرگیری یا تلاش مجدد برای درخواست‌های بارگذاری، خطای سرور 5xx برگردانده شد، از استراتژی پس‌گیری نمایی استفاده کنید. این خطاها ممکن است درصورت بارگیری بیش‌ازحد سرور رخ دهند. پس‌گیری نمایی می‌تواند به کاهش این نوع مشکلات در دوره‌های حجم بالای درخواست‌ها یا ترافیک سنگین شبکه کمک کند.

• انواع دیگر درخواست‌ها نباید با «پس‌گیری نمایی» مدیریت شوند اما همچنان می‌توانید تعدادی از آن‌ها را دوباره امتحان کنید. هنگام امتحان مجدد این درخواست‌ها، تعداد دفعات امتحان مجدد را محدود کنید. برای مثال، کد شما می‌تواند تعداد تلاش‌های مجدد را قبل‌از گزارش خطا به ده بار یا کمتر محدود کند.

• هنگام انجام بارگذاری‌های ازسرگیری‌پذیر، خطاهای 404 Not Found و 410 Gone را با شروع مجدد کل بارگذاری از ابتدا مدیریت کنید.

پس‌گیری نمایی

عقب‌گرد نمایی یک استراتژی استاندارد برای مدیریت خطاهای برنامه‌های شبکه‌ای است که در آن کارخواه به‌صورت دوره‌ای درخواست ناموفق را در مدت زمان رو به افزایش امتحان مجدد می‌کند. اگر حجم بالای درخواست‌ها یا ترافیک سنگین شبکه باعث شود سرور خطا برگرداند، پس‌گیری نمایی می‌تواند استراتژی خوبی برای مدیریت این خطاها باشد. برعکس، این استراتژی برای مقابله با خطاهایی که به حجم شبکه یا زمان پاسخ مربوط نیستند، مانند اطلاعات اعتباری غیرمعتبر یا خطاهای پیدا نشدن فایل، استراتژی مناسبی نیست.

درصورت استفاده صحیح، عقب‌گرد نمایی کارایی استفاده از پهنای باند را افزایش می‌دهد، تعداد درخواست‌های لازم برای دریافت پاسخ موفق را کاهش می‌دهد، و گذردهی درخواست‌ها را در محیط‌های هم‌زمان به حداکثر می‌رساند.

جریان پیاده‌سازی پس‌گیری نمایی ساده به این صورت است:

1. درخواستی به API ارسال کنید.
2. پاسخ HTTP 503 دریافت کنید که نشان می‌دهد باید درخواست را دوباره امتحان کنید.
3. ‫۱ ثانیه + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
4. پاسخ HTTP 503 دریافت کنید که نشان می‌دهد باید درخواست را دوباره امتحان کنید.
5. ‫۲ ثانیه + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
6. پاسخ HTTP 503 دریافت کنید که نشان می‌دهد باید درخواست را دوباره امتحان کنید.
7. ‫۴ ثانیه + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
8. HTTP 503 response دریافت کنید که نشان می‌دهد باید درخواست را دوباره امتحان کنید.
9. ‫۸ ثانیه + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
10. HTTP 503 response دریافت کنید که نشان می‌دهد باید درخواست را دوباره امتحان کنید.
11. ‫۱۶ ثانیه + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
12. Stop (توقف). خطایی را گزارش یا ثبت کنید.

در فهرست بالا، random_number_milliseconds یک عدد تصادفی برحسب میلی‌ثانیه است که کمتر یا مساوی ۱۰۰۰ است. این کار ضروری است، زیرا معرفی یک تأخیر تصادفی کوچک به توزیع یکنواخت‌تر بار کمک می‌کند و از احتمال هجوم به سرور جلوگیری می‌کند. مقدار random_number_milliseconds باید پس‌از هر انتظار دوباره تعریف شود.

الگوریتم طوری تنظیم شده است که وقتی n به ۵ برسد، خاتمه یابد. این سقف از تلاش بی‌نهایت کارخواه‌ها جلوگیری می‌کند و درنتیجه، قبل‌از اینکه درخواست به‌عنوان «خطای غیرقابل‌بازیابی» درنظر گرفته شود، حدود ۳۲ ثانیه تأخیر ایجاد می‌کند. تعداد حداکثر بیشتر برای تلاش مجدد خوب است، به‌ویژه اگر بارگذاری طولانی درحال انجام باشد؛ فقط مطمئن شوید که تأخیر تلاش مجدد را در حد معقولی، مثلاً کمتر از یک دقیقه، محدود کنید.

راهنمای کتابخانه کارخواه میانای برنامه‌سازی کاربردی

• .NET

• Java

• PHP

• Python

• Ruby