API किसी नोड या सेवा तक पहुँच देती है जिसकी अपनी सीमाएँ और निर्भरताएँ हैं। Ethereum में स्थिति पूछना या सिमुलेट करना लेन-देन प्रकाशित करने से अलग है। ये उदाहरण Ethereum के हैं, हर ब्लॉकचेन के नहीं।
पढ़ने और भेजने के प्रभाव अलग हैं
Ethereum में eth_call चेन पर लेन-देन बनाए बिना कॉल चलाता है; RPC प्रदाता अपनी सेवा का शुल्क ले सकता है। eth_sendRawTransaction पहले से हस्ताक्षरित लेन-देन भेजता है। पहचानकर्ता मिलना शामिल होने या सफल होने का प्रमाण नहीं है। रसीद, स्थिति, संबंधित ब्लॉक और नेटवर्क के अनुरूप अंतिमता जाँचें।
निर्भरताओं और विफलताओं का प्रबंधन करें
हस्ताक्षर से पहले नेटवर्क, कॉन्ट्रैक्ट पता, इंटरफ़ेस और पैरामीटर जाँचें। स्थिति बदलने पर सिमुलेशन बाद के परिणाम की गारंटी नहीं देता। निष्पादित लेकिन विफल लेन-देन में भी gas खर्च हो सकती है। स्मार्ट कॉन्ट्रैक्ट एक प्रोग्राम है; नाम से त्रुटिहीनता या समझौते की कानूनी वैधता तय नहीं होती।
तय करने योग्य नियंत्रण
- हस्ताक्षर अधिकार, खर्च सीमा और कुंजी प्रबंधन तय करें।
- RPC बंद होने और लंबित, विफल या पुनर्गठित लेन-देन का अंतर समझें।
- ओरेकल बाहरी तथ्य देता हो तो स्रोत, शासन और संभावित त्रुटियाँ जाँचें।
स्रोत
- Ethereum · JSON-RPC API
- Ethereum · Transactions
- Ethereum · Gas and fees
- Ethereum · Smart contracts
- Ethereum · Oracles
संपादकीय जाँच: 31 अक्टूबर 2026।
सबमिट किए गए, शामिल किए गए और इंटरप्रेट किए गए ट्रांज़ैक्शन को अलग करें।
एक ट्रांज़ैक्शन आइडेंटिफायर इंटेंडेड इफ़ेक्ट को एस्टैब्लिश नहीं करता है। नेटवर्क, रिसीट, शामिल करना, स्टेटस और रिलेवेंट बिज़नेस इवेंट चेक करें। इस्तेमाल की गई चेन के लिए कन्फर्मेशन और रिकवरी पॉलिसी डिफाइन करें; जब तक रिज़ल्ट अनसर्टेन रहें, इंटरफ़ेस को सक्सेस अनाउंस नहीं करना चाहिए।
- क्वेरी किए गए नेटवर्क और आइडेंटिफायर को वेरिफाई करें।
- पेंडिंग, फेल्ड एग्जीक्यूशन और कन्फर्म्ड इफ़ेक्ट को अलग करें।
- बिज़नेस एक्शन को रिप्ले किए बिना रिपीटेड नोटिफ़िकेशन को टेस्ट करें।
क्या रिटर्न किया गया हैश का मतलब है कि ऑपरेशन खत्म हो गया है?
नहीं। यह सबमिट किए गए ट्रांज़ैक्शन की पहचान करता है। नतीजों को ट्रैक करने और समझने के लिए चेन और कॉन्ट्रैक्ट के हिसाब से चेक की ज़रूरत होती है; बिना सोचे-समझे किसी ऑपरेशन को दोबारा सबमिट न करें।
प्राथमिक स्रोत: Ethereum — JSON-RPC and transaction receipts. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API कोटा और दर सीमाएँ
सीमाएँ क्षमता, पुनः प्रयास और ग्राहकों के बँटवारे को प्रभावित करती हैं।
- दर्ज करें कि कोटा खाते, कुंजी या संसाधन पर लागू है और क्लाइंट कितने समानांतर कार्य स्वीकार करता है। औसत दर कम होने पर भी असीमित कतार सेवा पर अधिक भार डाल सकती है।
- 429 में Retry-After हो तो उसे समझें और अगली माँग से पहले प्रतीक्षा करें। बढ़ती प्रतीक्षा और क्लाइंट के बीच समय वितरण को अधिकतम प्रयास और कुल समय सीमा से जोड़ें।
- लेखन का उत्तर खो जाए तो दोहराने से पहले स्थिति जाँचें। अनुकरण में कोटा, देर से उत्तर और रद्द करना मिलाएँ; कतार बिना दोहराए प्रभाव के समाप्त होनी चाहिए।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}अपेक्षित निर्णय
30 सेकंड प्रतीक्षा करें, 20 वर्करों के प्रयास अलग समय पर करें और पुनः प्रयास सीमित रखें।
बीस क्लाइंट: पुनः प्रयास बाँटें और गिनें
काल्पनिक उदाहरण: 20 वर्कर +0 s पर अलग-अलग 429 उत्तर और Retry-After: 30 प्राप्त करते हैं। समय-सारणी एक संभावित वितरण है, सर्वर क्षमता की गारंटी नहीं। हर वर्कर के पास शुरुआती अनुरोध के अलावा 3 पुनः प्रयास हैं।
| नीति | गणना या समय-सारणी | प्रभाव और सीमा |
|---|---|---|
| एक साथ पुनः प्रयास | 20 × 1 = 20 @ +30 s | 30 सेकंड प्रतीक्षा करने से समय का निर्देश पूरा होता है, लेकिन सभी 20 अनुरोध साथ लौटते हैं और भार फिर बढ़ सकता है। |
| फैले हुए पुनः प्रयास | 4 × 5 = 20 @ +30…+34 s | पाँच सेकंड तक प्रति सेकंड चार अनुरोध भेजने से 20 पुनः प्रयास फैलते हैं, उनकी संख्या घटती नहीं। यह उदाहरण क्रमिक प्रतीक्षा और यादृच्छिक अंतर वाली नीति का विकल्प नहीं है। |
| 25 सेकंड की समय-सीमा | 25 s < 30 s → 0 | यदि बचा समय आवश्यक 30 सेकंड से कम है, तो अनुबंध के अनुसार रोकें या स्थगित करें। समय-सीमा के लिए प्रतीक्षा कम न करें। |
| अधिकतम बजट | 20 × (1 + 3) = 80 | सभी प्रयास इस्तेमाल करने पर 20 शुरुआती अनुरोध और 60 पुनः प्रयास, कुल 80 अनुरोध होते हैं। सीमा सफलता या सुरक्षित दोहराव की गारंटी नहीं है। |
सत्यापन प्रक्रिया
- कोटा दायरा और पुनः प्रयास बजट दर्ज करें।
- केवल अधिकृत परीक्षण में कोटा खत्म करें।
- 429, Retry-After और सीमित समयक्रम रखें। तकनीकी सीमा और व्यावसायिक परिणाम में अंतर करें; समाप्त कोटे को शून्य स्टॉक बताने वाले उत्तर में न बदलें।
- बाहरी भार बिना चार परतों के तीन कुल कॉल का अनुकरण कर प्रयास गिनें।
- काल्पनिक कतार कार्य समाप्त करें और नया कार्य न शुरू होने की पुष्टि करें।
- काल्पनिक विफलता बाद अधिकृत काम धीरे लौटाएँ और कॉल, सीमा तथा विशिष्ट परिणाम बचाएँ।
क्या 429 साबित करता है कि पिछला लेखन नहीं हुआ?
नहीं। खोए उत्तर वाले कार्य का अलग मिलान आवश्यक है; दूसरी कोशिश के उत्तर से उसकी स्थिति न निकालें।
प्राथमिक स्रोत: IETF — RFC 6585, HTTP 429. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API: परतों में गुणा होते पुनः प्रयास रोकें
ऐप, SDK, प्रॉक्सी और सेवा एक कॉल फिर कर सकते हैं। चार काल्पनिक परतों में हर एक के तीन कुल प्रयास अंतिम विफल निर्भरता पर अधिकतम81 कॉल देते हैं। कोटा नियंत्रण में साझा बजट और उपयोगी समय सीमा जोड़ें।
- ऐप, SDK, प्रॉक्सी और निर्भरता के स्वतः प्रयास लिखें। जिम्मेदार परत चुनें और अनुबंध अनुसार अतिरिक्त प्रयास बंद या समन्वित करें। पहला प्रयास कुल बजट में गिनें। कार्य ID बचाएँ और गैर-इडेम्पोटेंट पुनः प्रयास से पहले अनिश्चित असर जाँचें।
- क्लाइंट की असली सीमा अनुसार प्रतीक्षा, कनेक्शन और प्रक्रिया सहित कुल अंतिम समय तय करें। कतार में प्रवेश से पहले समाप्त कार्य अस्वीकार करें। स्थानीय रद्द करना सर्वर रोकना साबित नहीं करता; स्थिति मिलाएँ। सारी कतारें एक साथ चालू किए बिना धीरे वापसी जाँचें।
हर परत पर तीन प्रयास क्या कुल तीन हैं?
नहीं। चार काल्पनिक परतों पर तीन कुल प्रयास से अंतिम निर्भरता पर अधिकतम3⁴ = 81 कॉल होते हैं।
समाप्त कार्य दूर का असर रद्द करता है?
जरूरी नहीं। नया बेकार काम रोके; शुरू दूर कार्य की स्थिति और संभव क्षतिपूर्ति जाँचें।
प्राथमिक स्रोत: AWS — Timeouts, retries, and backoff with jitter. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
