تحميل الصور باستخدام واجهة برمجة التطبيقات Play Games Services Publishing API

تتيح لك واجهة برمجة التطبيقات Play Games Services Publishing API تحميل صورة لأحد موارد الألعاب.

خيارات التحميل

تتيح لك واجهة برمجة التطبيقات Play Games Services Publishing API تحميل أنواع معيّنة من البيانات الثنائية أو الوسائط. يتم تحديد الخصائص المحدّدة للبيانات التي يمكنك تحميلها في صفحة المرجع الخاصة بأي طريقة تتيح تحميل الوسائط:

  • الحدّ الأقصى لحجم ملف التحميل: الحدّ الأقصى لكمية البيانات التي يمكنك تخزينها باستخدام هذه الطريقة.

  • أنواع MIME المقبولة للوسائط: هي أنواع البيانات الثنائية التي يمكنك تخزينها باستخدام هذه الطريقة.

يمكنك تقديم طلبات التحميل بأي من الطرق التالية. حدِّد الطريقة التي تستخدمها من خلال معلّمة الطلب uploadType.

  • تحميل بسيط: uploadType=media لنقل الملفات الصغيرة بسرعة، مثل 5 ميغابايت أو أقل

  • التحميل المتعدد الأجزاء: uploadType=multipart لنقل الملفات الصغيرة والبيانات الوصفية بسرعة، يتم نقل الملف مع البيانات الوصفية التي تصفه، وكل ذلك في طلب واحد.

  • التحميل القابل للاستئناف: uploadType=resumable. لنقل البيانات بشكل موثوق، وهو أمر مهم بشكل خاص مع الملفات الأكبر حجمًا. باستخدام هذه الطريقة، يمكنك استخدام طلب بدء جلسة يمكن أن يتضمّن بيانات وصفية بشكل اختياري. وهذه استراتيجية جيدة يمكن استخدامها لمعظم التطبيقات، لأنّها تعمل أيضًا مع الملفات الأصغر حجمًا مقابل طلب HTTP إضافي واحد لكل عملية تحميل.

عند تحميل الوسائط، يمكنك استخدام معرّف موارد موحّد خاص. في الواقع، تتضمّن الطرق التي تتيح تحميل الوسائط نقطتَي نهاية لمعرّف الموارد المنتظم (URI):

  • معرّف الموارد المنتظم /upload الخاص بالوسائط تنسيق نقطة نهاية التحميل هو معرّف الموارد المنتظم (URI) العادي مع البادئة "/upload". استخدِم معرّف الموارد المنتظم (URI) هذا عند نقل بيانات الوسائط نفسها.

    مثال: 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. يجب ضبطها على أحد أنواع بيانات الوسائط المقبولة للتحميل في الطريقة، كما هو محدّد في مرجع Publishing API.

  • استبدِل 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

تتضمّن عناوين HTTP العالية المستوى التي يجب استخدامها عند تقديم طلب تحميل متعدد الأجزاء ما يلي:

-Content-Type: اضبط القيمة على multipart/related وأدرِج سلسلة الحدود التي تستخدمها لتحديد أجزاء الطلب.

‫-Content-Length: يتم ضبطها على إجمالي عدد وحدات البايت في نص الطلب. يجب أن يكون حجم الجزء الخاص بالوسائط في الطلب أقل من الحد الأقصى لحجم الملف المحدّد لهذه الطريقة.

يتم تنسيق نص الطلب كنوع محتوى multipart/related RFC2387 ويحتوي على جزأين بالضبط. يتم تحديد الأجزاء من خلال سلسلة حدود، ويتبع سلسلة الحدود النهائية شرطتان.

يحتاج كل جزء من الطلب المتعدد الأجزاء إلى عنوان Content-Type إضافي:

  • جزء البيانات الوصفية: يجب أن يظهر أولاً، ويجب أن يتطابق Content-Type مع أحد تنسيقات البيانات الوصفية المقبولة.

  • جزء الوسائط: يجب أن يأتي ثانيًا، ويجب أن يتطابق Content-Type مع أحد أنواع MIME للوسائط المقبولة في الطريقة.

راجِع مرجع Publishing API للاطّلاع على قائمة بأنواع MIME المقبولة للوسائط والحدود القصوى لحجم الملفات التي يتم تحميلها لكل طريقة.

مثال: التحميل المتعدد الأجزاء

يعرض المثال أدناه طلب تحميل متعدد الأجزاء لواجهة برمجة التطبيقات 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. احفظ معرّف الموارد المنتظم (URI) للجلسة القابلة للاستئناف. احفظ معرّف URI للجلسة الذي تم عرضه في رد الطلب الأوّلي، لأنّك ستستخدمه في الطلبات المتبقية في هذه الجلسة. حمّل الملف.

  3. أرسِل ملف الوسائط إلى معرّف الموارد المنتظم (URI) الخاص بالجلسة القابلة للاستئناف.

بالإضافة إلى ذلك، يجب أن تتضمّن التطبيقات التي تستخدم ميزة التحميل القابل للاستئناف رمزًا برمجيًا لاستئناف عملية تحميل تمّت مقاطعتها. في حال توقّف عملية التحميل، يمكنك معرفة مقدار البيانات التي تم تلقّيها بنجاح، ثم استئناف عملية التحميل بدءًا من تلك النقطة.

بدء جلسة قابلة للاستئناف

لبدء عملية تحميل قابلة للاستئناف، أرسِل طلب POST أو PUT إلى معرّف الموارد المنتظم (URI) الخاص بالطريقة /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. يتم ضبطها على عدد وحدات البايت المقدَّمة في نص هذا الطلب الأوّلي. هذا الحقل غير مطلوب إذا كنت تستخدم ترميز النقل المقسَّم.

راجِع مرجع Publishing API للاطّلاع على قائمة بأنواع MIME المقبولة للوسائط والحدود القصوى لحجم الملفات التي يتم تحميلها لكل طريقة.

مثال: طلب بدء جلسة قابلة للاستئناف

يوضّح المثال التالي كيفية بدء جلسة قابلة للاستئناف في واجهة برمجة التطبيقات Play Games Services Publishing API.

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
}

يوضّح القسم التالي كيفية التعامل مع الردّ.

حفظ معرّف الموارد المنتظم (URI) الخاص بالجلسة القابلة للاستئناف

في حال نجاح طلب بدء الجلسة، يستجيب خادم واجهة برمجة التطبيقات برمز حالة HTTP 200 OK. بالإضافة إلى ذلك، يوفّر عنوان Location يحدّد معرّف الموارد المنتظم (URI) الخاص بالجلسة القابلة للاستئناف. يتضمّن العنوان Location، الموضّح في المثال أدناه، جزءًا من مَعلمة طلب البحث upload_id يمنح معرّف التحميل الفريد الذي سيتم استخدامه لهذه الجلسة.

مثال: استجابة بدء جلسة قابلة للاستئناف

في ما يلي الردّ على الطلب في الخطوة 1:

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، كما هو موضّح في مثال الاستجابة أعلاه، هي معرّف الموارد المنتظم (URI) للجلسة الذي ستستخدمه كنقطة نهاية HTTP لإجراء عملية تحميل الملف الفعلية أو الاستعلام عن حالة التحميل.

انسخ معرّف الموارد المنتظم (URI) الخاص بالجلسة واحفظه لتتمكّن من استخدامه في الطلبات اللاحقة.

تحميل الملف

لتحميل الملف، أرسِل طلب PUT إلى معرّف الموارد المنتظم الخاص بالتحميل الذي حصلت عليه في الخطوة السابقة. تنسيق طلب التحميل هو:

PUT session_uri

تتضمّن عناوين HTTP التي يجب استخدامها عند إرسال طلبات تحميل الملفات القابلة للاستئناف ما يلي: Content-Length اضبط هذا الحقل على عدد البايتات التي يتم تحميلها في هذا الطلب، وهو عادةً حجم ملف التحميل.

مثال: طلب تحميل ملف يمكن استئنافه

في ما يلي طلب قابل للاستئناف لتحميل ملف PNG بالكامل بحجم 2,000,000 بايت للمثال الحالي.

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-Range، بالإضافة إلى عنوان Content-Length المطلوب لعمليات تحميل الملفات الكاملة:

  • Content-Length: يجب ضبطها على حجم الجزء أو أقل، كما قد يكون الحال بالنسبة إلى الطلب الأخير.

  • Content-Range: اضبط هذا الحقل لعرض عدد وحدات البايت في الملف الذي تحمّله. على سبيل المثال، يشير Content-Range: bytes 0-524287/2000000 إلى أنّك تقدّم أول 524,288 بايت (256 × 1024 × 2) في ملف بحجم 2,000,000 بايت.

استئناف عملية تحميل تمت مقاطعتها

إذا تم إنهاء طلب تحميل قبل تلقّي رد أو إذا تلقّيت الرد HTTP 503 Service Unavailable من الخادم، عليك استئناف عملية التحميل التي تمّت مقاطعتها. لاستئناف عملية تحميل تمّت مقاطعتها، اتّبِع الخطوات التالية:

  1. حالة الطلب يمكنك الاستعلام عن الحالة الحالية لعملية التحميل من خلال إرسال طلب PUT فارغ إلى معرّف الموارد المنتظم (URI) الخاص بعملية التحميل. بالنسبة إلى هذا الطلب، يجب أن تتضمّن عناوين HTTP العنوان Content-Range الذي يشير إلى أنّ الموضع الحالي في الملف غير معروف. على سبيل المثال، اضبط قيمة Content-Range على */2000000 إذا كان إجمالي طول الملف يبلغ 2,000,000. إذا كنت لا تعرف الحجم الكامل للملف، اضبط Content-Range على */*.

  2. الحصول على عدد وحدات البايت التي تم تحميلها معالجة الردّ من طلب الحالة يستخدم الخادم العنوان Range في استجابته لتحديد عدد البايتات التي تلقّاها حتى الآن. على سبيل المثال، يشير العنوان Range الذي يتضمّن 0-299999 إلى أنّه تم تلقّي أول 300,000 بايت من الملف.

  3. تحميل البيانات المتبقية أخيرًا، بعد أن عرفت مكان استئناف الطلب، أرسِل البيانات المتبقية أو الجزء الحالي. يُرجى العِلم أنّه عليك التعامل مع البيانات المتبقية كجزء منفصل في كلتا الحالتين، لذا عليك إرسال العنوان Content-Range عند استئناف عملية التحميل.

مثال: استئناف عملية تحميل تمّت مقاطعتها

  1. طلب معرفة حالة التحميل يستخدم الطلب التالي العنوان Content-Range للإشارة إلى أنّ الموضع الحالي في الملف الذي يبلغ حجمه 2,000,000 بايت غير معروف.

    PUT {session_uri} HTTP/1.1
    Content-Length: 0
    Content-Range: bytes */2000000
    
  2. استخرِج عدد وحدات البايت التي تم تحميلها حتى الآن من الردّ. يستخدم رد الخادم العنوان Range للإشارة إلى أنّه تلقّى أول 43 بايت من الملف حتى الآن. استخدِم القيمة العليا لعنوان Range لتحديد موضع بدء عملية التحميل التي تم استئنافها.

    HTTP/1.1 308 Resume Incomplete
    Content-Length: 0
    Range: 0-42
    
  3. استأنِف عملية التحميل من حيث توقّفت. يستأنف الطلب التالي عملية التحميل من خلال إرسال وحدات البايت المتبقية من الملف، بدءًا من وحدة البايت رقم 43.

    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. إرسال طلب إلى واجهة برمجة التطبيقات
  2. تلقّي الردّ HTTP 503، ما يشير إلى أنّه عليك إعادة محاولة الطلب
  3. انتظِر لمدة ثانية واحدة + رقم_عشوائي_بالملّي ثانية وأعِد محاولة إجراء الطلب.
  4. تلقّي الردّ HTTP 503، ما يشير إلى أنّه عليك إعادة محاولة الطلب
  5. انتظِر لمدة ثانيتَين + random_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
  6. تلقّي الردّ HTTP 503، ما يشير إلى أنّه عليك إعادة محاولة الطلب
  7. انتظِر لمدة 4 ثوانٍ + random_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
  8. تلقّي الرمز HTTP 503 response، ما يشير إلى أنّه عليك إعادة محاولة الطلب
  9. انتظِر لمدة 8 ثوانٍ + random_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
  10. تلقّي الرمز HTTP 503 response، ما يشير إلى أنّه عليك إعادة محاولة الطلب
  11. انتظِر لمدة 16 ثانية + random_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
  12. إيقاف الإبلاغ عن خطأ أو تسجيله

في القائمة أعلاه، random_number_milliseconds هو عدد عشوائي من الملّي ثانية أقل من أو يساوي 1000. هذا الإجراء ضروري، لأنّ إضافة تأخير عشوائي صغير يساعد في توزيع الحمل بشكل أكثر توازناً وتجنُّب إمكانية الضغط على الخادم. يجب إعادة تحديد قيمة random_number_milliseconds بعد كل فترة انتظار.

تم ضبط الخوارزمية على التوقف عندما تكون قيمة n هي 5. يمنع هذا الحدّ الأقصى العملاء من إعادة المحاولة إلى ما لا نهاية، ويؤدي إلى تأخير إجمالي يبلغ حوالي 32 ثانية قبل اعتبار الطلب "خطأً غير قابل للاسترداد". لا بأس من زيادة الحد الأقصى لعدد محاولات إعادة الإرسال، خاصةً إذا كان التحميل يستغرق وقتًا طويلاً، ولكن احرص على ألا يتجاوز التأخير في إعادة المحاولة مدة معقولة، مثلاً أقل من دقيقة واحدة.

أدلة مكتبات العملاء في واجهات برمجة التطبيقات