पैकेज बनाएं

फ़ाइल अपलोड करने के विकल्प

Android Over The Air API की मदद से, पैकेज डेटा अपलोड करके एक नया पैकेज संसाधन बनाया जा सकता है. ये ओटीए पैकेज हैं. इन्हें एक या उससे ज़्यादा कॉन्फ़िगरेशन के साथ जोड़ा जा सकता है, ताकि डिवाइसों पर अपडेट भेजा जा सके.

हम Linux और Windows के लिए बाइनरी उपलब्ध कराते हैं, ताकि फिर से शुरू किए जा सकने वाले पैकेज अपलोड किए जा सकें. इसके लिए, नीचे बताए गए प्रोटोकॉल लागू करने के बजाय, हम इनका इस्तेमाल मुफ़्त में कर सकते हैं. अगर आपको ज़्यादा इंटिग्रेशन चाहिए, तो कृपया नीचे दिए गए प्रोटोकॉल में से किसी एक का इस्तेमाल करें.

ध्यान दें: हमारी सेवा की शर्तों के तहत, ये बाइनरी बिना किसी सहायता के उपलब्ध कराई जाती हैं.

Linux

Linux के लिए, Android Over The Air API v1 अपलोडर क्लाइंट डाउनलोड करें.

Windows

Windows के लिए, Android Over The Air API v1 अपलोडर क्लाइंट डाउनलोड करें.

इसका इस्तेमाल करने के लिए, आपको सबसे पहले एक सेवा खाता बनाना होगा और उस खाते के लिए एक JSON कुंजी फ़ाइल डाउनलोड करनी होगी. कृपया खाता बनाने के लिए हमारी गाइड यहां देखें.
बाइनरी और कुंजी फ़ाइल मिलने पर, उसे कमांड लाइन के विकल्पों के साथ चलाया जा सकता है. ऐसा करने पर कुंजी, डिप्लॉयमेंट, और अपलोड किए जाने वाले पैकेज के बारे में जानकारी दी जा सकती है. सभी विकल्पों को देखने के लिए, कृपया --help का इस्तेमाल करें.

प्रोटोकॉल अपलोड करें

इन तरीकों से फ़ाइल अपलोड करने के अनुरोध किए जा सकते हैं. X-Goog-Upload-Protocol अनुरोध के हेडर के साथ, इस्तेमाल किया जा रहा तरीका बताएं.

• एक से ज़्यादा हिस्सों में अपलोड: X-Goog-Upload-Protocol: multipart. छोटी फ़ाइलों और मेटाडेटा को तेज़ी से ट्रांसफ़र करने के लिए, फ़ाइल को उसके बारे में बताने वाले मेटाडेटा के साथ ट्रांसफ़र करें. यह सब कुछ एक ही अनुरोध में किया जा सकता है.
• फिर से अपलोड किया जा सकता है: X-Goog-Upload-Protocol: resumable. फ़ाइल ट्रांसफ़र करने का सही तरीका है, खास तौर पर बड़ी फ़ाइलों के लिए. इस तरीके में, सेशन शुरू करने के अनुरोध का इस्तेमाल किया जाता है. इसमें विकल्प के तौर पर मेटाडेटा भी शामिल किया जा सकता है. ज़्यादातर ऐप्लिकेशन के लिए, यह एक अच्छी रणनीति है. ऐसा इसलिए है, क्योंकि यह छोटी फ़ाइलों के लिए भी काम करती है. इसके लिए, हर अपलोड पर एक और एचटीटीपी अनुरोध का शुल्क चुकाना होता है.

एक से ज़्यादा फ़ाइलों को अपलोड करने की सुविधा

अगर आपकी तरफ़ से भेजा जा रहा डेटा इतना छोटा है कि कनेक्शन टूट जाने पर भी उसे फिर से अपलोड किया जा सकता है, तो यह एक अच्छा विकल्प है.

एक से ज़्यादा हिस्सों में अपलोड किए गए डेटा का इस्तेमाल करने के लिए, /upload/package यूआरआई के लिए POST अनुरोध करें और X-Goog-Upload-Protocol को multipart पर सेट करें.

कई हिस्सों में डेटा अपलोड करने का अनुरोध करते समय, इस्तेमाल किए जाने वाले टॉप-लेवल एचटीटीपी हेडर में ये शामिल हैं:

• Content-Type. अनुरोध के हिस्सों की पहचान करने के लिए, इसका इस्तेमाल मल्टीपार्ट/मिलते-जुलते पर सेट करें और उस सीमा स्ट्रिंग को शामिल करें जिसका इस्तेमाल किया जा रहा है.
• Content-Length. अनुरोध के मुख्य हिस्से में कुल बाइट की संख्या सेट करें.

अनुरोध के मुख्य हिस्से को multipart/related के कॉन्टेंट टाइप [RFC2387] के तौर पर फ़ॉर्मैट किया जाता है और इसमें दो हिस्से होते हैं. हिस्सों की पहचान बाउंड्री स्ट्रिंग से की जाती है और आखिरी सीमा स्ट्रिंग के बाद दो हाइफ़न होते हैं.

एक से ज़्यादा हिस्सों वाले अनुरोध के हर हिस्से के लिए एक अतिरिक्त Content-Type हेडर ज़रूरी है:

1. मेटाडेटा का हिस्सा: सबसे पहले आना चाहिए और Content-Type को application/json होना चाहिए.
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--

अगर अनुरोध पूरा हो जाता है, तो सर्वर एचटीटीपी 200 OK स्टेटस कोड दिखाता है

HTTP/1.1 200

curl और oauth2l का इस्तेमाल करके, इसे आसानी से पूरा किया जा सकता है. नीचे अनुरोध का एक सैंपल दिया गया है, जिसमें यह माना जाता है कि आपने सेवा कुंजी का इस्तेमाल किया है (ज़्यादा जानकारी के लिए, हमारा अनुमति देने का तरीका देखें).

कर्ल अनुरोध का उदाहरण

    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. फिर से शुरू किया जा सकने वाला सेशन शुरू करें. अपलोड यूआरआई से जुड़ा शुरुआती अनुरोध करें, जिसमें मेटाडेटा शामिल हो. साथ ही, यह फिर से शुरू किए जा सकने वाले यूनीक अपलोड लोकेशन के बारे में बताता हो.
2. फिर से शुरू किए जा सकने वाले सेशन यूआरआई को सेव करें. शुरुआती अनुरोध के जवाब में मिले सेशन यूआरआई को सेव करें. आपको इस सेशन के बाकी अनुरोधों के लिए इसका इस्तेमाल करना होगा.
3. फ़ाइल अपलोड करें. ZIP फ़ाइल का पूरा या कुछ हिस्सा, फिर से शुरू किए जा सकने वाले सेशन यूआरआई को भेजें.

इसके अलावा, फिर से शुरू किए जा सकने वाले अपलोड का इस्तेमाल करने वाले ऐप्लिकेशन में कोड की ज़रूरत होगी, ताकि बाकी अपलोड को फिर से शुरू किया जा सके. अगर आपके अपलोड की प्रोसेस में रुकावट आती है, तो देखें कि कितना डेटा मिला है. इसके बाद, अपलोड की प्रोसेस को दोबारा शुरू करें.

ध्यान दें: अपलोड किए गए यूआरआई की समयसीमा तीन दिनों के बाद खत्म हो जाती है.

पहला चरण: फिर से शुरू किया जा सकने वाला सेशन शुरू करना

फिर से शुरू किए जाने लायक अपलोड शुरू करने के लिए, /upload/package यूआरआई के लिए POST अनुरोध करें और X-Goog-Upload-Protocol को resumable पर सेट करें.

अनुरोध करने के इस अनुरोध के लिए, मुख्य हिस्से में सिर्फ़ मेटाडेटा शामिल होना चाहिए. आपको उस फ़ाइल का असल कॉन्टेंट ट्रांसफ़र करना होगा जिसे आपको बाद के अनुरोधों में अपलोड करना है.

शुरुआती अनुरोध के साथ, यहां दिए गए एचटीटीपी हेडर इस्तेमाल करें:

• 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" }

अगले सेक्शन में, दिए गए जवाब को मैनेज करने का तरीका बताया गया है.

दूसरा चरण: फिर से शुरू होने लायक सेशन यूआरआई को सेव करें

अगर सेशन शुरू करने का अनुरोध पूरा हो जाता है, तो एपीआई सर्वर एक एचटीटीपी 200 OK स्टेटस कोड के साथ जवाब देता है. इसके अलावा, यह एक X-Goog-Upload-URL हेडर देता है जो आपके फिर से शुरू किए जा सकने वाले सेशन यूआरआई के बारे में बताता है. नीचे दिए गए उदाहरण में दिखाए गए X-Goog-Upload-URL हेडर में, upload_id क्वेरी पैरामीटर वाला हिस्सा शामिल है. यह हिस्सा, इस सेशन के लिए इस्तेमाल करने के लिए यूनीक अपलोड आईडी देता है. इस जवाब में एक X-Goog-Upload-Status हेडर भी होता है. अगर अपलोड करने का अनुरोध मान्य और स्वीकार किया गया था, तो यह active फ़ॉर्मैट में होगा. अगर अपलोड अस्वीकार कर दिया गया था, तो यह स्थिति final हो सकती है.

उदाहरण: शुरू किए जा सकने वाले सेशन का जवाब

पहले चरण में अनुरोध का जवाब यहां दिया गया है:

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 हेडर की वैल्यू, जैसा कि ऊपर दिए गए उदाहरण में दिखाया गया है. सेशन यूआरआई को असल में फ़ाइल अपलोड करने या अपलोड के स्टेटस की क्वेरी करने के लिए, एचटीटीपी एंडपॉइंट के तौर पर इस्तेमाल किया जाएगा.

सेशन यूआरआई को कॉपी करके सेव करें, ताकि आप बाद के अनुरोधों के लिए इसका इस्तेमाल कर सकें.

चरण 3: फ़ाइल अपलोड करें

फ़ाइल अपलोड करने के लिए, अपलोड यूआरआई को POST अनुरोध भेजें जो आपको पिछले चरण में मिला था. अपलोड के अनुरोध का फ़ॉर्मैट यह है:

POST session_uri

फिर से शुरू किए जाने लायक फ़ाइल अपलोड अनुरोध करने के लिए इस्तेमाल किए जाने वाले एचटीटीपी हेडर में ये शामिल हैं:

1. Content-Length. इसे इस अनुरोध में अपलोड किए जाने वाले बाइट की संख्या पर सेट करें, जो आम तौर पर अपलोड की जाने वाली फ़ाइल का साइज़ होता है.
2. X-Goog-Upload-Command. इसे upload और finalize पर सेट करें.
3. X-Goog-Upload-Offset. इससे वह ऑफ़सेट बताया गया जिस पर बाइट लिखी जानी चाहिए. ध्यान दें कि क्लाइंट को क्रम से बाइट अपलोड करनी होंगी.

उदाहरण: फ़ाइल अपलोड करने का अनुरोध फिर से शुरू किया जा सकता है

मौजूदा उदाहरण के लिए, 20,00,000 बाइट वाली ZIP फ़ाइल को फिर से अपलोड करने का अनुरोध फिर से शुरू किया जा सकता है.

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

अगर अनुरोध पूरा हो जाता है, तो सर्वर एचटीटीपी 200 Ok के साथ जवाब देता है.

अगर अपलोड के अनुरोध में रुकावट आती है या आपको सर्वर से एचटीटीपी 503 Service Unavailable या 5xx का कोई दूसरा रिस्पॉन्स मिलता है, तो जिस अपलोड में रुकावट आई थी उसे फिर से शुरू करें में बताया गया तरीका अपनाएं.

---

फ़ाइल को कई हिस्सों में अपलोड करना

फिर से शुरू किए जाने लायक अपलोड की मदद से, किसी फ़ाइल को कई हिस्सों में बांटा जा सकता है. साथ ही, हर हिस्से को क्रम से अपलोड करने के लिए, कई अनुरोधों को भेजा जा सकता है. हालांकि, यह हमारा सुझाव नहीं है, क्योंकि अन्य अनुरोधों के साथ परफ़ॉर्मेंस की लागत जुड़ी होती है. आम तौर पर, इसकी ज़रूरत नहीं पड़ती. हमारा सुझाव है कि क्लाइंट, पेलोड के बाकी सभी बाइट अपलोड करें और हर upload कमांड के साथ finalize कमांड शामिल करें.

हालांकि, किसी एक अनुरोध में ट्रांसफ़र किए गए डेटा को कम करने के लिए, आपको छोटे-छोटे हिस्सों में डेटा का इस्तेमाल करना पड़ सकता है. इससे कई काम किए जा सकते हैं. जैसे, उन लेगसी ब्राउज़र के लिए अपलोड प्रोग्रेस के संकेत देना जिन पर डिफ़ॉल्ट रूप से यह सुविधा उपलब्ध नहीं होती.

ज़्यादा जानकारी के लिए बड़ा करें

अगर डेटा को कई हिस्सों में अपलोड किया जा रहा है, तो अपलोड किए जाने वाले ऑफ़सेट को बताने के लिए X-Goog-Upload-Offset का इस्तेमाल करें.

• Content-Length. समूह के आकार पर सेट करें या शायद उससे कम आकार पर सेट करें, जैसा कि पिछले अनुरोध में किया गया था.
• X-Goog-Upload-Offset. इससे वह ऑफ़सेट बताया गया जिस पर बाइट लिखी जानी चाहिए. ध्यान दें कि क्लाइंट को क्रम से बाइट अपलोड करनी होंगी.

चंक साइज़ की पाबंदी: सर्वर, X-Goog-Upload-Chunk-Granularity हेडर का इस्तेमाल करके जवाब दे सकता है. यह क्लाइंट के भेजे गए सभी हिस्सों के बाइट अलाइनमेंट और साइज़ की जानकारी के बारे में बताता है. सभी हिस्सों का साइज़ उस ऑफ़सेट से शुरू होना चाहिए जो इस हेडर की वैल्यू से अलाइन है. साथ ही, आखिरी हिस्से को छोड़कर, बाकी सभी हिस्सों का साइज़ ऐसा होना चाहिए जो इस हेडर की वैल्यू का एक से ज़्यादा हो. अगर हेडर सर्वर से नहीं मिला है, तो अलाइनमेंट या जानकारी के स्तर की कोई ज़रूरत नहीं है.

उदाहरण: छोटी-छोटी फ़ाइलों को फिर से अपलोड करने का अनुरोध

पहली 5,24,288 बाइट भेजने वाला अनुरोध ऐसा दिख सकता है:

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

bytes 0-524288

अगर अनुरोध पूरा हो जाता है, तो सर्वर एचटीटीपी 200 Ok के साथ जवाब देता है.

अगर किसी समूह के PUT अनुरोध में रुकावट आती है या आपको सर्वर से एचटीटीपी 503 Service Unavailable या कोई दूसरा 5xx रिस्पॉन्स मिलता है, तो बाधित अपलोड को फिर से शुरू करें में बताया गया तरीका अपनाएं. हालांकि, बाकी की फ़ाइल अपलोड करने के बजाय, उस समय से हिस्सों को अपलोड करना जारी रखें.

अहम जानकारी:

• सभी हिस्सों को भेजने के बाद, सेशन को पूरा करना न भूलें.
• अपलोड करने वाले हर यूआरआई की एक तय समयसीमा होती है. बाद में, इसकी समयसीमा खत्म हो जाती है. अगर इसका इस्तेमाल नहीं किया जाता है, तो एक दिन के अंदर ही इसकी समयसीमा खत्म हो जाती है. इस वजह से, बेहतर है कि अपलोड यूआरआई मिलते ही आप फिर से शुरू किए जा सकने वाले अपलोड शुरू कर दें. साथ ही, रुकावट आने के कुछ समय बाद ही, किसी रुकावट वाले अपलोड को फिर से शुरू करें.
• अगर ऐसे अपलोड सेशन आईडी के साथ अनुरोध भेजा जाता है जिसकी समयसीमा खत्म हो चुकी है, तो सर्वर 404 Not Found स्टेटस कोड दिखाता है. इस मामले में, आपको फिर से शुरू किया जा सकने वाला नया अपलोड शुरू करना होगा, एक नया अपलोड यूआरआई पाना होगा, और नए एंडपॉइंट का इस्तेमाल करके, अपलोड को शुरू से शुरू करना होगा.

जब फ़ाइल अपलोड हो जाती है, तो सर्वर एचटीटीपी 200 Ok के साथ X-Goog-Upload-Status को final पर सेट करता है.

---

जिस अपलोड में रुकावट आई थी उसे फिर शुरू करना

अगर जवाब मिलने से पहले ही अपलोड करने का अनुरोध खत्म कर दिया जाता है या आपको सर्वर से एचटीटीपी 503 Service Unavailable रिस्पॉन्स मिलता है, तो आपको रोके गए अपलोड को फिर से शुरू करना होगा. इसके लिए, यह तरीका अपनाएं:

1. अनुरोध की स्थिति. अपलोड के यूआरएल को अनुरोध भेजकर अपलोड किए जाने वाले डेटा की मौजूदा स्थिति के बारे में क्वेरी करें. इसमें X-Goog-Upload-Command को query पर सेट किया जाएगा.

   ध्यान दें: सिर्फ़ अपलोड में रुकावट आने पर नहीं, बल्कि हिस्सों के बीच स्टेटस देखने का अनुरोध किया जा सकता है. उदाहरण के लिए, अगर आपको लेगसी ब्राउज़र के लिए, अपलोड होने की स्थिति से जुड़े संकेत दिखाने हैं, तो यह तरीका काम का है.

2. अपलोड किए गए बाइट की संख्या पाएं. स्टेटस क्वेरी से मिले रिस्पॉन्स को प्रोसेस करें. सर्वर अपने रिस्पॉन्स में X-Goog-Upload-Size-Received हेडर का इस्तेमाल करके, यह बताता है कि उसे अब तक कितनी बाइट मिली हैं.
3. बाकी डेटा को अपलोड करें. आखिर में, अब आपको पता है कि अनुरोध को फिर से शुरू करना है, तो बचा हुआ डेटा या मौजूदा डेटा भेजें. ध्यान दें कि किसी भी मामले में, आपको बाकी बचे डेटा को एक अलग हिस्से के तौर पर मानना होगा. इसलिए, अपलोड फिर से शुरू करते समय, आपको 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 हेडर की जांच करनी होगी. अगर हेडर मौजूद है और वैल्यू 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
• अगर अपलोड के अनुरोधों को फिर से शुरू करने या फिर से कोशिश करते समय, सर्वर की कोई गड़बड़ी 5xx मिलती है, तो एक्स्पोनेंशियल बैकऑफ़ रणनीति का इस्तेमाल करें. सर्वर पर ज़रूरत से ज़्यादा लोड होने पर, ये गड़बड़ियां हो सकती हैं. बड़ी संख्या में किए जाने वाले अनुरोधों या ज़्यादा नेटवर्क ट्रैफ़िक के दौरान, घातांकीय बैकऑफ़ से इस तरह की समस्याओं को कम किया जा सकता है.
• अन्य तरह के अनुरोधों को एक्सपोनेन्शियल बैकऑफ़ से हैंडल नहीं किया जाना चाहिए, लेकिन फिर भी आप उनकी संख्या के लिए फिर से कोशिश कर सकते हैं. इन अनुरोधों का फिर से प्रयास करते समय, इनकी फिर से कोशिश करने की संख्या को सीमित करें. उदाहरण के लिए, किसी गड़बड़ी की शिकायत करने से पहले, आपका कोड 10 या उससे कम बार कोशिश कर सकता है.
• दोबारा अपलोड करने की शुरुआत से शुरू करते हुए, फिर से अपलोड किए जा सकने वाले वीडियो अपलोड करते समय 404 Not Found गड़बड़ियों को ठीक करें.

एक्सपोनेंशियल बैकऑफ़

एक्सपोनेन्शियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ियों को मैनेज करने की स्टैंडर्ड रणनीति है. इसमें क्लाइंट समय-समय पर, अनुरोध न कर पाने की कोशिश को बार-बार करता रहता है. अगर अनुरोधों की ज़्यादा संख्या या ज़्यादा नेटवर्क ट्रैफ़िक की वजह से सर्वर, गड़बड़ियां दिखाता है, तो एक्स्पोनेंशियल बैकऑफ़, उन गड़बड़ियों को ठीक करने का एक अच्छा तरीका हो सकता है. इसके उलट, यह नेटवर्क वॉल्यूम या जवाब मिलने में लगने वाले समय से जुड़ी गड़बड़ियों को ठीक करने के लिए काम की रणनीति नहीं है. जैसे, पुष्टि करने के अमान्य क्रेडेंशियल या फ़ाइल नहीं मिलने की गड़बड़ियां.

एक्स्पोनेंशियल बैकऑफ़ सुविधा का इस्तेमाल सही तरीके से किया जाए, तो इसका इस्तेमाल करने से बैंडविथ के इस्तेमाल की क्षमता बढ़ जाती है और कामयाब रिस्पॉन्स पाने के लिए अनुरोधों की संख्या कम हो जाती है. साथ ही, यह एक साथ काम करने वाली जगहों पर अनुरोधों की संख्या को बढ़ाता है.

सिंपल एक्सपोनेन्शियल बैकऑफ़ लागू करने का फ़्लो इस तरह है:

1. एपीआई से अनुरोध करें.
2. HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
3. 1 सेकंड + random_number_मिलीसेकंड तक इंतज़ार करें और फिर से कोशिश करें.
4. HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
5. दो सेकंड + random_number_मिलीसेकंड तक इंतज़ार करें और फिर से कोशिश करें.
6. HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
7. 4 सेकंड रैंडम नंबर_मिलीसेकंड तक इंतज़ार करें और फिर से कोशिश करें.
8. HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
9. आठ सेकंड से ज़्यादा समय तक किसी भी समय इंतज़ार करें और फिर से कोशिश करें.
10. HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
11. 16 सेकंड + यादृच्छिक_number_मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
12. वीडियो बंद करने के लिए. किसी गड़बड़ी की रिपोर्ट करें या उसे लॉग करें.

ऊपर दिए गए फ़्लो में, random_number_मिलीसेकंड, 1,000 या उससे कम या उसके बराबर मिलीसेकंड की कोई रैंडम संख्या है. यह ज़रूरी है, क्योंकि थोड़ा भी समय के लिए देरी करने से लोड को ज़्यादा समान रूप से डिस्ट्रिब्यूट करने में मदद मिलती है. साथ ही, सर्वर पर स्टैंप लगाए जाने की संभावना से बचा जा सकता है. हर इंतज़ार के बाद, रैंडम नंबर_मिलीसेकंड की वैल्यू फिर से तय करनी चाहिए.

ध्यान दें: इंतज़ार हमेशा (2 ^ n) + random_number_मिलीसेकंड होता है, जहां n एक तरह से बढ़ने वाला पूर्णांक होता है. शुरुआत में इसकी वैल्यू 0 से तय होती है. हर इटरेशन (हर अनुरोध) के लिए, पूर्णांक n में 1 की बढ़ोतरी होती है.

n 5 के होने पर एल्गोरिदम खत्म हो जाता है. यह सीलिंग क्लाइंट को दोबारा कोशिश करने से रोकती है. इसकी वजह से, किसी अनुरोध को "ठीक न की जा सकने वाली गड़बड़ी" माना जाने से पहले, करीब 32 सेकंड की देरी हो जाती है. ज़्यादा से ज़्यादा संख्या में बार-बार कोशिश करने से कोई परेशानी नहीं होती. खास तौर पर तब, जब वीडियो अपलोड करने की एक लंबी प्रोसेस चल रही हो. बस कोशिश करें कि दोबारा कोशिश करने के लिए एक मिनट से कम समय दें.