---
title: "सामान्य प्रश्न - Geyser gRPC स्ट्रीम"
description: "ERPC - Enhanced Solana RPC Geyser gRPC स्ट्रीम के बारे में अक्सर पूछे जाने वाले प्रश्न"
canonical: "https://erpc.global/hi/faq/grpc/general/"
locale: "hi"
---

# सामान्य प्रश्न - Geyser gRPC स्ट्रीम

## Q. आपके नोड किन क्षेत्रों में स्थित हैं?

वर्तमान में हम निम्नलिखित क्षेत्रों में नोड्स का संचालन करते हैं:

- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- New York (NY)
- Tokyo (TY)
- Singapore (SGP)
- Sydney (SYD)

ERPC वास्तविक रूटिंग पथ पर आधारित वास्तविक नेटवर्क विलंबता को मापता है, जो सीधी रेखा की दूरी पर निर्भर रहने के बजाय स्वचालित रूप से सबसे कम विलंबता वाले क्षेत्र का चयन करता है। यह दृष्टिकोण न केवल व्यक्तिगत उपयोगकर्ताओं के लिए विलंबता को बेहतर बनाता है, बल्कि समग्र नेटवर्क दक्षता को भी बढ़ाता है और संभावित हमलों के खिलाफ ERPC के वैश्विक लचीलेपन को मजबूत करता है।

यदि आपके वातावरण में इष्टतम क्षेत्र स्वचालित रूप से नहीं चुना जाता है, तो कृपया ERPC Web Dashboard के माध्यम से हमसे संपर्क करें।

ERPC Web Dashboard: https://dashboard.erpc.global/hi

## Q. विलंबता 9999ms दिखाई देती है और कोई गैर-इष्टतम क्षेत्र चुन लिया जाता है। मुझे क्या करना चाहिए?

gRPC क्षेत्र चयन के लिए, ERPC नीचे सूचीबद्ध प्रॉक्सी होस्ट से आपके पंजीकृत IP पर ICMP लेटेंसी प्रोब भेजता है। सूचीबद्ध प्रत्येक स्रोत IP से आने वाले ICMP इको अनुरोधों को अनुमति दें। यदि फ़ायरवॉल (ufw, क्लाउड फ़ायरवॉल, सुरक्षा समूह आदि) उन्हें ब्लॉक करता है, तो माप `9999ms` हो सकता है और कोई गैर-इष्टतम क्षेत्र चुना जा सकता है। एक क्षेत्र में कई IP अलग-अलग प्रोब होस्ट हैं; उन सभी की आवश्यकता है।

[ERPC_PING_SOURCES:grpc]: #
| क्षेत्र | ICMP स्रोत IP |
| --- | --- |
| 🇳🇱 Amsterdam | `82.21.43.34`, `151.244.92.36` |
| 🇺🇸 New York | `151.243.244.5` |
| 🇩🇪 Frankfurt | `151.241.178.20`, `151.241.178.34`, `151.241.178.21` |
| 🇬🇧 London | `151.241.65.4` |
| 🇯🇵 Tokyo | `143.20.238.66` |
| 🇸🇬 Singapore | `151.245.186.2` |
| 🛰️ Far Point | `143.20.238.73` |

## Q. मैंने अपनी IP allowlist कर दी है, फिर भी कनेक्ट नहीं हो रहा। क्या जाँचना चाहिए?

Dashboard में चुने गए एन्क्रिप्टेड HTTPS endpoint का उपयोग करें; HTTPS port 443 का उपयोग करता है। Port 80 पर HTTP अनएन्क्रिप्टेड कम-विलंबता विकल्प बना रहता है।

दोनों ट्रांसपोर्ट एक ही पंजीकृत-IP allowlist का उपयोग करते हैं। Dashboard में चुना endpoint लें: HTTPS के लिए 443 या HTTP के लिए 80।

- HTTPS endpoint: Dashboard में चुने गए endpoint को port 443 पर उपयोग करें।
- HTTP endpoint: Dashboard में चुने गए endpoint को port 80 पर उपयोग करें।
- Dashboard में दिखाई गई URL को `https://` या `http://` के साथ उपयोग करें।

प्रमाणीकरण आपके पंजीकृत IP पते पर आधारित है। जब तक किसी विशेष product page पर स्पष्ट रूप से ऐसा करने को न कहा गया हो, तब तक `x-token`, `token` या `Authorization` headers न जोड़ें।

## Q. मैंने पहले केवल WebSocket का उपयोग किया है। क्या मैं gRPC का उपयोग कर सकता हूँ? क्या आपके पास नमूने हैं?

हाँ, आप SLV का उपयोग करके gRPC के साथ जल्दी से परीक्षण और विकास शुरू कर सकते हैं।

एक साझा endpoint के लिए जिसे आप बिना किसी token के परीक्षण कर सकते हैं, चलाएँ:

```bash
slv check grpc --endpoint <YOUR_ENDPOINT> --token none
```

विवरण के लिए हमारी [gRPC क्विकस्टार्ट गाइड](https://slv.dev/hi/doc/geyser-grpc/quickstart/) देखें।

## Q. क्या मैं दो IP पते पंजीकृत कर सकता हूँ?

आप प्रति subscription एक endpoint का उपयोग कर सकते हैं। यदि आप दो IP पतों का उपयोग करना चाहते हैं, तो आपको दो अलग-अलग subscriptions लेने होंगे।

## Q. क्या फ़िल्टर की कोई सीमा है?

Shared Geyser gRPC में fair-use सुरक्षा है ताकि एक stream अन्य ERPC ग्राहकों के लिए आवश्यक संसाधन न ले ले। वर्तमान Shared नियम में हर non-empty `blocks` map अस्वीकार होता है, भले ही block अनुरोध संकीर्ण हो। हर account filter में `account`, `owner` या समर्थित cuckoo filter होना चाहिए; केवल `memcmp` या `dataSize` पर्याप्त नहीं है।

अस्वीकृत shape हटाएँ और केवल वही डेटा subscribe करें जिसकी आपके application को आवश्यकता है। transaction subscription या block metadata पूर्ण block के बिना आवश्यकता पूरी कर सकते हैं। जब वैध workload Shared shape या resource allowance से बड़ा हो तो Dedicated Geyser gRPC उपयुक्त है; वह invalid parameter को वैध नहीं बनाता और न ही slow client को ठीक करता है।

## Q. दोबारा कनेक्ट करने से पहले gRPC error कैसे एकत्र करूँ?

Reconnect loop उसे बदल दे उससे पहले पहला error सहेजें। Initial metadata और trailers से gRPC status और message के साथ `x-erpc-error-code`, `x-erpc-error-reason`, और `x-erpc-doc-url` भी दर्ज करें। ERPC pause दे तो `x-erpc-retry-after-seconds` और `x-erpc-retry-at` (Unix seconds) भी रिकॉर्ड करें।

त्रुटि `ERPC [STREAM_GUARD_SLOW_READER]: ...` के रूप में दिख सकती है। दिखी हुई त्रुटि या उसका code FAQ search में डालें। canonical स्पष्टीकरण के लिए [ERPC gRPC FAQ](https://erpc.global/hi/faq/grpc/general/) देखें। कनेक्शन जल्दी समाप्त हो तो trailer मिलने की अपेक्षा न करें।

आप symptom से भी खोज सकते हैं: slow receiver, disconnected, bandwidth, delivery lag, backlog, pause, retry, invalid argument, resource exhausted, permission denied, IP registration, too many streams, full blocks, या all accounts।

## Q. कौन-से gRPC errors मेरे connection को pause करते हैं, और मेरे client को reconnect करना कब बंद करना चाहिए?

Pause एक तय अवधि है जिसे ERPC कुछ errors के बाद लागू करता है। जब तक pause सक्रिय है, client को reconnect नहीं करना चाहिए।

**क्या count होता है।** ये errors count होते हैं, और ये चरणों का एक ही क्रम साझा करते हैं:

- हर वह Subscribe request जिसे ERPC `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` या `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` के साथ अस्वीकार करता है, पहले request सहित। पहला counted error warning है, जिससे कोई pause शुरू नहीं होती।
- `STREAM_GUARD_SLOW_READER`। हालाँकि, अगर delivery lag ERPC की ओर से पैदा होता है, तो ERPC stream को count किए बिना बंद करता है, और error में कोई retry समय नहीं होता।

ये count नहीं होते: खुद reconnect करना, चार `STREAM_ADMISSION_*` codes (`STREAM_ADMISSION_LIMIT_REACHED`, `STREAM_ADMISSION_IP_NOT_ADMITTED`, `STREAM_ADMISSION_SOURCE_UNAVAILABLE` और `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE`), और कोई भी counted error जो pause सक्रिय रहने के दौरान होता है। Pause के दौरान हुआ counted error उस pause को नहीं बढ़ाता और अगले चरण पर नहीं ले जाता।

**चरण।** हर counted error इस क्रम में एक चरण आगे ले जाता है; यह क्रम warning से शुरू होता है:

- Warning: कोई pause नहीं।
- 60 सेकंड की pause।
- 300 सेकंड की pause।
- 1800 सेकंड की pause।
- 86400 सेकंड (24 घंटे) की pause। यह अंतिम चरण है: इस चरण पर हर counted error 86400 सेकंड की एक और pause शुरू करता है।

Warning वाले चरण पर, अगला counted error 60 सेकंड की pause पर तभी ले जाता है जब वह warning के 1 घंटे के भीतर आए। Warning के 1 घंटे से अधिक बाद आने वाला counted error बिना pause की एक और warning है, और तब 1 घंटे की window उसी नई warning से शुरू होती है।

पिछले count हुए error के 60 सेकंड से कम समय बाद आने वाला counted error उसी error के हिस्से के रूप में count होता है और कोई चरण आगे नहीं ले जाता।

**चरण warning पर कब लौटते हैं।** एक बार चरणों से pause शुरू हो जाने के बाद, वे warning पर तभी लौटते हैं जब पिछली pause के अंत से मापकर 24 घंटे बिना किसी counted error और बिना किसी pause के बीत जाएँ; उसके बाद अगला counted error बिना pause की warning होता है। तब तक, अगला counted error बिना warning के तुरंत अगला चरण शुरू करता है।

**Egress pause।** `STREAM_GUARD_EGRESS_BUDGET` 600 सेकंड की अपनी स्थिर pause शुरू करता है। यह चरणों को आगे नहीं बढ़ाता।

**समाप्ति समय कहाँ मिलता है।**

- जो error pause शुरू करता है, उसमें `Retry after N seconds.` और headers `x-erpc-retry-after-seconds` और `x-erpc-retry-at` (Unix seconds) होते हैं। Warning में कोई retry समय नहीं होता।
- जब कोई counted अस्वीकृत request ही pause शुरू करता है, तो वह अपने code के बजाय `ResourceExhausted (8)` के साथ `STREAM_GUARD_SHAPE_REJECT_PENALTY` के रूप में लौटता है।
- Slow-reader या egress pause के दौरान, reconnect को शेष समय के साथ `STREAM_GUARD_PENALTY_ACTIVE` मिलता है।
- अस्वीकृत request से शुरू हुई pause के दौरान, नया connection बिना किसी gRPC status और बिना ERPC code के तुरंत बंद कर दिया जाता है। जो connection अभी खुला है, उस पर किसी request का उत्तर उस connection के बंद होने से पहले फिर से `STREAM_GUARD_SHAPE_REJECT_PENALTY` और शेष समय के साथ दिया जा सकता है। हो सकता है कि client समाप्ति समय फिर कभी न देखे, इसलिए उसे `x-erpc-retry-at` उस पहले error से सहेजना चाहिए जिसमें यह मौजूद हो।

| Code | gRPC स्थिति | क्या यह pause शुरू करता है या आगे बढ़ाता है? | Client को क्या करना चाहिए |
| --- | --- | --- | --- |
| `ERPC_GRPC_INVALID_ARGUMENT` | `InvalidArgument (3)` | हाँ, जब यह किसी Subscribe request को अस्वीकार करता है। तब यह ऊपर दिए गए चरणों के अंतर्गत एक counted error है। | Loop रोकें और वही request दोबारा न भेजें। नीचे इसकी अपनी entry में बताया गया है कि क्या जाँचें। |
| `STREAM_GUARD_SHAPE_BLOCKS` | `PermissionDenied (7)` | हाँ। यह ऊपर दिए गए चरणों के अंतर्गत एक counted error है। | Loop रोकें और वही request दोबारा न भेजें। नीचे इसकी अपनी entry में बताया गया है कि क्या जाँचें। |
| `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` | `PermissionDenied (7)` | हाँ। यह ऊपर दिए गए चरणों के अंतर्गत एक counted error है। | Loop रोकें और वही request दोबारा न भेजें। नीचे इसकी अपनी entry में बताया गया है कि क्या जाँचें। |
| `STREAM_GUARD_SLOW_READER` | `ResourceExhausted (8)` | हाँ। यह ऊपर दिए गए चरणों के अंतर्गत एक counted error है। हालाँकि, अगर delivery lag ERPC की ओर से पैदा होता है, तो ERPC stream को count किए बिना बंद करता है, और error में कोई retry समय नहीं होता। | Loop रोकें। नीचे इसकी अपनी entry में बताया गया है कि क्या जाँचें। अगर इससे pause शुरू हुई हो, तो `x-erpc-retry-at` में दिए गए समय से पहले reconnect न करें। |
| `STREAM_GUARD_EGRESS_BUDGET` | `ResourceExhausted (8)` | हाँ। यह ऊपर दिए गए चरणों के बाहर 600 सेकंड की स्थिर pause शुरू करता है। | `x-erpc-retry-at` में दिए गए समय से पहले reconnect न करें। नीचे इसकी अपनी entry में बताया गया है कि क्या जाँचें। |
| `STREAM_GUARD_SHAPE_REJECT_PENALTY` | `ResourceExhausted (8)` | हाँ। यह वह counted अस्वीकृत request है जिसने pause शुरू की। यह अभी खुले connection पर शेष समय के साथ फिर से लौट सकता है। | `x-erpc-retry-at` में दिए गए समय से पहले reconnect न करें। अस्वीकृत request ठीक करें और उसे बिना बदले दोबारा न भेजें। |
| `STREAM_GUARD_PENALTY_ACTIVE` | `ResourceExhausted (8)` | नहीं। यह पहले से सक्रिय slow-reader या egress pause की सूचना देता है। | `x-erpc-retry-at` में दिए गए समय से पहले reconnect न करें। |
| `STREAM_ADMISSION_LIMIT_REACHED` | `ResourceExhausted (8)` | नहीं। इसमें कोई समयबद्ध pause नहीं होती। | अप्रयुक्त streams बंद करें, फिर retry करें। |
| `STREAM_ADMISSION_IP_NOT_ADMITTED` | `PermissionDenied (7)` | नहीं। इसमें कोई समयबद्ध pause नहीं होती। | नीचे इसकी अपनी entry में बताया गया है कि क्या जाँचें। |
| `STREAM_ADMISSION_SOURCE_UNAVAILABLE` | `Unavailable (14)` | नहीं। इसमें कोई समयबद्ध pause नहीं होती। | सामान्य तरीके से back off करें और delay के बाद फिर प्रयास करें। |
| `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` | `Unavailable (14)` | नहीं। इसमें कोई समयबद्ध pause नहीं होती। | सामान्य तरीके से back off करें और delay के बाद फिर प्रयास करें। |

**Client को क्या करना चाहिए।** Counted error मिलने पर loop रोकें, वही request दोबारा न भेजें, और उसे ठीक करें। Pause के दौरान `x-erpc-retry-at` में दिए गए समय से पहले reconnect न करें। अस्वीकृत Subscribe requests ऊपर दिए गए नियमों के अंतर्गत count होते हैं, और reconnect करना count नहीं होता।

## Q. slow receiver के disconnected होने पर `STREAM_GUARD_SLOW_READER` का `ResourceExhausted (8)` के साथ क्या अर्थ है?

ERPC ने इस stream में अपर्याप्त write progress या delivery lag देखा। केवल delivery lag से कारण तय नहीं होता। Network loss, effective bandwidth, host hardware और application consumer के साथ बने रहने की जाँच करें। Subscribed data को सीमित करें और receive loop के बाहर bounded queue में processing करें। Bounded queue memory नियंत्रित करती है, पर लगातार slow consumer को ठीक नहीं कर सकती। ERPC retry deadline दे तो reconnect से पहले उसकी प्रतीक्षा करें। नीचे दिया गया प्रश्न “मेरा gRPC stream एक ही speed पर क्यों टिका रहता है और पीछे क्यों छूटता जाता है?” receive window और उसे अपनी client library में बढ़ाने का तरीका बताता है।

## Q. मेरा gRPC stream एक ही speed पर क्यों टिका रहता है और पीछे क्यों छूटता जाता है?

आपके client में, या उसके और ERPC के बीच की किसी चीज़ में, छोटी receive window होने से `STREAM_GUARD_SLOW_READER` के साथ stream कट सकता है और उसके बाद pause लग सकती है। यह उत्तर बताता है कि receive window क्या है, कैसे पता करें कि वह आपके stream को सीमित कर रही है या नहीं, और हर library में उसे कैसे बढ़ाएँ। ऊपर दिया गया प्रश्न “कौन-से gRPC errors मेरे connection को pause करते हैं, और मेरे client को reconnect करना कब बंद करना चाहिए?” चरण और उनकी अवधि बताता है।

**Receive window क्या है।** HTTP/2 में receiver, sender को बताता है कि receiver के पुष्टि करने से पहले कितना data भेजा जा सकता है; यही मात्रा receive window (HTTP/2 flow control window) है। एक round trip में अधिकतम एक window जितना data जाता है, इसलिए speed लगभग उस मान पर रुक जाती है जो window को round-trip time (endpoint तक जाकर वापस आने का समय) से भाग देने पर मिलता है।

**बाकी सीमाएँ।** Window दो होती हैं, एक हर stream के लिए और एक हर connection के लिए (connection के सभी streams इसे साझा करते हैं), और इनमें से छोटी window सीमा तय करती है। HTTP/2 specification में दोनों windows 65,535 bytes से शुरू होती हैं। TCP receive buffer (आने वाले data के लिए memory) भी इसी तरह speed को सीमित करता है। बीच में मौजूद proxy, load balancer, gateway, VPN या sidecar की अपनी windows और buffers होते हैं। वहाँ छोटी window या buffer stream पर सीमा लगा देता है, भले ही आपके अपने client की windows बड़ी हों।

**यह कैसा दिखता है।** Chain कितनी भी व्यस्त हो, एक stream लगभग एक ही speed पर टिक जाता है, और उसका delivery lag लगातार बढ़ता है। ERPC ने ऐसी जगह से मापा जहाँ से Frankfurt के Shared endpoint तक round-trip time लगभग 6 ms था, और हर run के बीच केवल window बदली:

- 16 KiB stream window: speed लगभग 2.7 MB/s पर स्थिर (16 KiB को 6 ms से भाग देने पर); delivery lag हर सेकंड लगभग 0.6 सेकंड बढ़ा और 45 सेकंड में 26 सेकंड तक पहुँच गया।
- दोनों 16 MiB: अधिकतम delivery lag 14 ms था।

अगर delivery lag ERPC की ओर से पैदा होता है, तो ERPC stream को count किए बिना बंद करता है, और error में कोई retry समय नहीं होता।

**जाँच कैसे करें।**

1. Stream की speed और delivery lag की तुलना ऊपर बताए गए pattern से करें।
2. Round-trip time मापें। Window का अनुमान लगाने के लिए stream की speed को round-trip time से गुणा करें (2.7 MB/s गुणा 6 ms लगभग 16 KB होता है)।
3. जाँचें कि आपके client की दोनों windows में से किसी का मान छोटा तो नहीं है, या automatic growth (library द्वारा window को खुद बढ़ाना) बंद तो नहीं है।
4. TCP receive buffer जाँचें। Linux पर `sysctl net.ipv4.tcp_rmem net.core.rmem_max` चलाएँ, और देखें कि आपकी application `SO_RCVBUF` set करती है या नहीं, क्योंकि इससे automatic sizing बंद हो जाती है।
5. बीच में मौजूद हर चीज़ की windows और buffers जाँचें।
6. अगर speed की कोई सीमा नहीं है और केवल lag बढ़ता है, तो receive करने के बाद की processing धीमी है। ऊपर दिया गया प्रश्न “slow receiver के disconnected होने पर `STREAM_GUARD_SLOW_READER` का `ResourceExhausted (8)` के साथ क्या अर्थ है?” बताता है कि receive loop को केवल पढ़ने तक कैसे सीमित रखें और भारी काम को bounded queue में कैसे ले जाएँ।

**Library के अनुसार settings।** उदाहरण दोनों windows को 16 MiB पर set करते हैं, जैसा ERPC के माप में था। जो library यहाँ नहीं दी गई है, उसके लिए HTTP/2 initial window settings खोजें।

**Rust, `yellowstone-grpc-client`।** Window settings के बिना `GeyserGrpcClient::build_from_shared` हर stream के लिए 2 MiB और हर connection के लिए 5 MiB इस्तेमाल करता है। 6 ms के round trip पर ये defaults 300 MB/s से अधिक की अनुमति देते हैं, इसलिए ये stream पर सीमा नहीं लगाते। Windows खुद set करने के लिए दोनों builder methods इस्तेमाल करें और `http2_adaptive_window` बंद रखें। इसे चालू करने पर window 65,535 bytes से शुरू होकर खुद 16 MiB तक बढ़ती है और आपके मानों को अनदेखा करती है।

```rust
// दोनों windows 16 MiB पर तय; http2_adaptive_window बंद रखें।
let client = GeyserGrpcClient::build_from_shared(endpoint)?
    .tls_config(ClientTlsConfig::new().with_native_roots())?
    .initial_stream_window_size(16 * 1024 * 1024)
    .initial_connection_window_size(16 * 1024 * 1024)
    .connect()
    .await?;
```

**TypeScript, `@triton-one/yellowstone-grpc` 5.0.1 या बाद के versions।** Defaults: हर stream के लिए 4 MiB, हर connection के लिए 8 MiB, automatic growth चालू। Window 64 KiB से शुरू होकर 16 MiB तक बढ़ती है, इसलिए defaults शायद ही कभी stream पर सीमा लगाते हैं। Sizes तय करने के लिए तीसरा argument `grpcHttp2AdaptiveWindow: false` के साथ दें।

```typescript
// Adaptive window बंद है, इसलिए ये तय sizes इस्तेमाल होते हैं।
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})
```

**TypeScript, `@triton-one/yellowstone-grpc` 5.0.0 या पहले के versions।** ये versions `@grpc/grpc-js` इस्तेमाल करते हैं, जिसकी default window 65,535 bytes है: 6 ms पर लगभग 11 MB/s, 100 ms पर लगभग 0.66 MB/s। Version 1.14 से `@grpc/grpc-js` `'grpc-node.flow_control_window'` को दोनों windows पर लागू करता है; version 1.13 में यह option सिर्फ़ stream window पर लागू होता है, इसलिए connection window 65,535 bytes पर ही रहती है (6 ms पर लगभग 11 MB/s)। अगर `@grpc/grpc-js` का version 1.14 से पुराना है, तो `@triton-one/yellowstone-grpc` 5.0.1 या बाद के version पर upgrade करना ज़्यादा तेज़ रास्ता है।

```typescript
// दोनों windows बढ़ाने के लिए @grpc/grpc-js 1.14 या बाद का version चाहिए।
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})
```

**Go, `google.golang.org/grpc`।** Default रूप से library windows को खुद 16 MiB तक बढ़ाती है। `grpc.WithInitialWindowSize` और `grpc.WithInitialConnWindowSize` उन्हें तय कर देते हैं और automatic growth बंद कर देते हैं; 64 KiB से कम मान अनदेखे किए जाते हैं। दोनों set करें: केवल एक set करने पर दूसरी window 64 KiB पर रहती है।

```go
// दोनों set करें; इससे automatic window growth भी बंद हो जाती है।
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)
```

**Python, `grpcio`।** `grpc.http2.bdp_probe` default रूप से चालू होता है, इसलिए windows खुद बढ़ती हैं; अगर आपका code `("grpc.http2.bdp_probe", 0)` pass करता है, तो उसे हटा दें। `grpc.http2.lookahead_bytes` हर stream के लिए read-ahead तय करता है (default 64 KB); लंबे round trip पर बड़े मान मदद कर सकते हैं।

```python
# अगर आपके options में ("grpc.http2.bdp_probe", 0) है, तो उसे हटा दें।
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])
```

**पास से receive करें।** छोटे round trip में वही window अधिक data पहुँचाती है, और ERPC की [VPS सेवा](https://erpc.global/hi/vps/) और [Bare-Metal सर्वर](https://erpc.global/hi/baremetal/) client को endpoint के पास रखते हैं।

**सोच-समझकर बाँटें।** हर registered source IP पर Standard में 10 streams और Premium में 50 streams की अनुमति है। हर stream को अपनी stream window मिलती है, लेकिन एक connection के streams एक ही connection window साझा करते हैं, इसलिए छोटी connection window फिर भी speed सीमित करती है। किसी stream को बदलते समय पहले पुराना stream बंद करें: खुले streams इसी limit में शामिल होते हैं, और limit पार करने पर `STREAM_ADMISSION_LIMIT_REACHED` मिलता है (इसका अपना प्रश्न नीचे है)। बाँटने से धीमी processing तेज़ नहीं होती।

## Q. `STREAM_GUARD_EGRESS_BUDGET` का `ResourceExhausted (8)` के साथ क्या अर्थ है?

IP का aggregate traffic Shared allowance से अधिक हो गया, इसलिए जुड़े हुए streams साथ में बंद हो सकते हैं। Data volume और अनावश्यक parallel streams घटाएँ, फिर लौटे हुए deadline तक प्रतीक्षा करें। यह egress pause 600 seconds का स्थिर है और penalty ladder को आगे नहीं बढ़ाता, हालांकि पहले से लगी अधिक लंबी pause लागू रह सकती है।

## Q. `STREAM_GUARD_PENALTY_ACTIVE` का `ResourceExhausted (8)` के साथ क्या अर्थ है?

पहले की slow-reader या egress pause अभी सक्रिय है, और इस response में शेष समय दिया गया है। पहला ERPC error बचाएँ, उसका कारण ठीक करें और `x-erpc-retry-at` से पहले reconnect न करें; जाँचने के लिए जल्दी reconnect न करें। Reconnect के प्रयास count नहीं होते। ऊपर दिया गया प्रश्न “कौन-से gRPC errors मेरे connection को pause करते हैं, और मेरे client को reconnect करना कब बंद करना चाहिए?” चरण और उनकी अवधि बताता है।

## Q. `STREAM_GUARD_SHAPE_BLOCKS` का `PermissionDenied (7)` के साथ क्या अर्थ है?

वर्तमान Shared नियम हर non-empty `blocks` map को अस्वीकार करता है, request संकीर्ण होने पर भी। `blocks` map हटा दें। आवश्यकता पूरी हो तो transactions और/या block metadata लें, पर दोनों पूर्ण block के बराबर नहीं हैं। पूर्ण blocks के लिए Dedicated Geyser gRPC उपयोग करें; इससे कोई selective-block Shared plan उपलब्ध होने का संकेत नहीं मिलता।

## Q. `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` का `PermissionDenied (7)` के साथ क्या अर्थ है?

Account-filter entry को `account`, `owner`, या supported cuckoo filter से data चुनना आवश्यक है। केवल `memcmp` और `dataSize` पर्याप्त नहीं हैं। Account request को इन supported shapes में से किसी एक तक सीमित करें, या पूर्ण account stream चाहिए तो Dedicated Geyser gRPC उपयोग करें।

## Q. `STREAM_GUARD_SHAPE_REJECT_PENALTY` का `ResourceExhausted (8)` के साथ क्या अर्थ है?

यह code `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` या `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` के बजाय तब लौटता है जब वही counted अस्वीकृत request pause शुरू करता है; ऊपर दिया गया प्रश्न “कौन-से gRPC errors मेरे connection को pause करते हैं, और मेरे client को reconnect करना कब बंद करना चाहिए?” बताता है कि ऐसा कब होता है। इसमें `Retry after N seconds.`, `x-erpc-retry-after-seconds` और `x-erpc-retry-at` होते हैं। इस pause के दौरान नए connections बिना किसी gRPC status और बिना ERPC code के तुरंत बंद कर दिए जाते हैं, इसलिए हो सकता है कि client समाप्ति समय फिर कभी न देखे। `x-erpc-retry-at` उस पहले error से सहेजें जिसमें यह मौजूद हो। अस्वीकृत Subscribe requests ऊपर दिए गए नियमों के अंतर्गत count होते हैं, और reconnect करना count नहीं होता। Request ठीक करें और उसे बिना बदले दोबारा न भेजें। जल्दी connection drop transport error जैसा दिख सकता है, इसलिए reconnect loop उसे छिपाए उससे पहले पहला ERPC error बचाएँ।

## Q. `STREAM_ADMISSION_LIMIT_REACHED` का `ResourceExhausted (8)` के साथ क्या अर्थ है?

Admission allowance अभी भरी हुई है। अप्रयुक्त या duplicate streams बंद करें, connection का allowance जाँचें और capacity उपलब्ध होने पर retry करें। केवल यह response होने से timed penalty सक्रिय होना सिद्ध नहीं होता।

## Q. `STREAM_ADMISSION_IP_NOT_ADMITTED` का `PermissionDenied (7)` के साथ क्या अर्थ है?

ERPC connection को admit नहीं कर सका, IP-registration grace period समाप्त होने के बाद भी। Actual outbound IP की registered IP से तुलना करें और current access state की पुष्टि करें। किसी fixed propagation time को माने बिना registration change फैलने दें, और स्थिति बनी रहे तो support से संपर्क करें।

## Q. `STREAM_ADMISSION_SOURCE_UNAVAILABLE` का `Unavailable (14)` के साथ क्या अर्थ है?

ERPC उस समय connection का source निर्धारित नहीं कर सका। Back off करें और delay के बाद फिर प्रयास करें। स्थिति बनी रहे तो पहले error और उसके metadata के साथ support से संपर्क करें; यह response ग्राहक के network या server में fault सिद्ध नहीं करता।

## Q. `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` का `Unavailable (14)` के साथ क्या अर्थ है?

ERPC उस समय access सत्यापित नहीं कर सका। Back off करें और delay के बाद फिर प्रयास करें; यह जारी रहे तो support से संपर्क करें। बार-बार re-register करना, filters फैलाना या Dedicated Geyser gRPC खरीदना इस availability response को ठीक नहीं करता।

## Q. `ERPC_GRPC_INVALID_ARGUMENT` का `InvalidArgument (3)` के साथ क्या अर्थ है?

Request में invalid parameters, options, field types, keys या filter combinations हैं। Retry से पहले request ठीक करें, और वही request दोबारा न भेजें। इस code के साथ अस्वीकार किया गया हर Subscribe request ऊपर दिए गए प्रश्न “कौन-से gRPC errors मेरे connection को pause करते हैं, और मेरे client को reconnect करना कब बंद करना चाहिए?” के pause नियमों के अंतर्गत एक counted error है; यही नियम `STREAM_GUARD_SHAPE_BLOCKS`, `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` और `STREAM_GUARD_SLOW_READER` पर भी लागू होते हैं। जब ऐसा कोई request pause शुरू करता है, तो वह `ResourceExhausted (8)` के साथ `STREAM_GUARD_SHAPE_REJECT_PENALTY` के रूप में लौटता है। Dedicated Geyser gRPC invalid parameters को वैध नहीं बनाता।

Error message कोड के अंत में `(reason: <token>)` जोड़ता है, और वही token response header `x-erpc-error-reason` में भी लौटाया जाता है। क्या बदलना है, यह देखने के लिए नीचे token खोजें। जहाँ कोई सीमा लागू होती है, error message उसे बताता है।

| कारण (reason) | इसका अर्थ | क्या बदलें |
| --- | --- | --- |
| `too_many_filters` | Request में एक request की अनुमति से अधिक named filter या data slice हैं। | हर request में इस प्रकार के named filter (या data slice) कम करें। |
| `empty_filter` | किसी filter में कोई address नहीं है, और खाली filter का अर्थ सब कुछ है। | हर filter में कम से कम एक address दें (accounts: एक account या owner; transactions: account की सूची)। Shared gRPC खाली filter को सर्व नहीं करता। |
| `too_many_addresses` | एक filter field में बहुत अधिक address दिए गए हैं। | एक filter field में कम address रखें; उन्हें कई filter में बाँटें या सूची छोटी करें। |
| `address_not_allowed` | किसी filter में ऐसा address है जिसे Shared gRPC अनुमति नहीं देता। | उस उच्च-वॉल्यूम address को filter से हटाएँ। |
| `filter_name_too_long` | Filter का नाम बहुत लंबा है। | छोटे filter नाम (map के key) इस्तेमाल करें। |
| `invalid_commitment` | Commitment level मान्य नहीं है। | `processed`, `confirmed` या `finalized` इस्तेमाल करें। |
| `invalid_address` | किसी filter में अमान्य address है। | हर address को मान्य base58 Solana address बनाएँ (खाली string, space या गलत लंबाई नहीं)। |
| `invalid_signature` | Transaction signature का मान मान्य नहीं है। | मान्य base58 transaction signature इस्तेमाल करें। |
| `invalid_account_data_filter` | Account का data filter मान्य नहीं है। | `memcmp`, `datasize` और token account data filter ठीक करें, और उनकी संख्या message में बताई गई सीमा के भीतर रखें। |
| `invalid_data_slice` | Data slice मान्य नहीं हैं। | Data slice को offset के क्रम में रखें और उन्हें एक-दूसरे पर overlap न होने दें। |
| `blocks_include_not_allowed` | blocks subscription के विकल्प Shared gRPC पर उपलब्ध नहीं हैं। | `blocks` हटाएँ और इसके बजाय transaction या `blocks_meta` subscription इस्तेमाल करें। |
| `invalid_token_accounts_mode` | Token accounts mode मान्य नहीं है। | `ALL` (0) या `BALANCE_CHANGED` (1) इस्तेमाल करें। |
| `invalid_argument` | ऊपर का कोई भी कारण लागू नहीं होता। | फिर से कोशिश करने से पहले request के filter और parameter जाँचें। |

## Q. `ERPC_GRPC_REQUEST_FAILED` का क्या अर्थ है जब gRPC कोई अन्य शून्येतर स्थिति लौटाता है?

Request एक valid gRPC status के साथ विफल हुई है और वही अगला कदम निर्धारित करता है। History range invalid हो तो `OutOfRange (11)` जैसे status के लिए request ठीक करें; `Unavailable (14)` जैसे availability status के लिए back off करें। हर non-zero status को transient न मानें और हर response को बिना बदले retry न करें।

## Q. आप किस क्षेत्र की सलाह देते हैं?

कोई एक स्थायी सर्वोत्तम क्षेत्र नहीं है। Solana वैश्विक है, और leader की भूमिका leader schedule के अनुसार validators के बीच बदलती रहती है। जिन क्षेत्रों में validators अधिक हैं और stake अधिक है, वहाँ leader slots अधिक बार आते हैं, जिससे transactions को तेज़ी से land होने में मदद मिल सकती है। इसका दूसरा पहलू यह है कि प्रतिस्पर्धी ट्रैफ़िक भी वहीं केंद्रित होता है, इसलिए आपकी रणनीति के आधार पर कम भीड़ वाला क्षेत्र कभी-कभी बेहतर परिणाम दे सकता है।

एक व्यावहारिक शुरुआत के रूप में, जब leader slots की स्थिर उपलब्धता सबसे अधिक मायने रखती हो, तो Frankfurt या US East Coast जैसा validator-सघन क्षेत्र चुनें, या जब सबसे छोटे पथ से निष्पादन प्राथमिकता हो, तो किसी विशिष्ट लक्षित validator के पास खुद को स्थापित करें। सार्वजनिक Solana नेटवर्क के वितरण को समझने के लिए [Validators Solutions](https://validators.solutions/) का उपयोग करें, फिर [ERPC Leader Slot API](https://erpc.global/hi/doc/rpc/leader-slot-api/) और वास्तविक मापों के आधार पर तय करें कि एकल-क्षेत्र, दोहरे-क्षेत्र या वैश्विक तैनाती में से कौन-सी उपयुक्त है।

[![Solana मेननेट वितरण रिपोर्ट](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/)

## Q. मुझे ~400ms या उससे कम विलंबता चाहिए।

लगभग 400ms के भीतर विलंबता हासिल करने के लिए, इन आवश्यक बिंदुओं पर विचार करें:

- **पिंग मानों की यथार्थवादी समझ**: पिंग मान आदर्श परिस्थितियों को दर्शाते हैं और स्ट्रीमिंग संचार की वास्तविक विलंबता नहीं दिखाते; स्ट्रीमिंग संचार में विलंबता आम तौर पर पिंग की लगभग 5 गुना होती है। उदाहरण के लिए, महाद्वीपों के बीच 100ms का पिंग व्यवहार में लगभग 500ms की विलंबता बन जाता है। इसलिए, ~400ms विलंबता हासिल करने के लिए बुनियादी ढांचा उसी क्षेत्र के भीतर स्थापित करना ज़रूरी है।
  - सामान्य पिंग मान (संदर्भ के लिए):
    - एक ही नेटवर्क: ~0.1ms
    - Private Network Interconnect (PNI): ~0.2ms
    - एक ही डेटा केंद्र: ~0.3ms
    - एक ही शहर: ~1ms
    - पड़ोसी देश: ~5–10ms
    - अंतरमहाद्वीपीय: ~100–300ms

- **औसत विलंबता के जाल से बचना**: Solana validator भौगोलिक रूप से विश्व भर में फैले हुए हैं, और leader schedule प्रत्येक epoch के साथ बेतरतीब ढंग से बदलता है। ~400ms हासिल करने के लिए औसत विलंबता पर निर्भर रहना अव्यावहारिक है। इसके बजाय, सबसे कम विलंबता वाले slots की पहचान करने के लिए आपको अपने विशिष्ट क्षेत्र में validator schedules को सटीक रूप से ट्रैक करना चाहिए। न्यूनतम विलंबता लगातार हासिल करने के लिए, सभी प्रासंगिक क्षेत्रों में बुनियादी ढांचे की आवश्यकता होती है। उसी क्षेत्र के भीतर, डेटा प्राप्ति दसियों मिलीसेकंड में हो सकती है, और संचरण केवल कुछ मिलीसेकंड में संभव है।

- **Leader Schedule को ट्रैक करना**: **ERPC Leader Slot API (`getLeaderSlots`)** का उपयोग करके अपने क्षेत्र के लिए leader validator schedule की निगरानी करें।
  यह आगामी leader schedule, वर्तमान epoch का stake weight, validators के अनुमानित भू-स्थान और संदर्भ पिंग मान लौटाता है, ताकि आप लक्ष्य बनाने के लिए सबसे कम विलंबता वाले slots को उनके आने से पहले ही पहचान सकें।
  सार्वजनिक मानचित्र-शैली डेटा और मूल RPC API व्यापक नेटवर्क दृश्यता के लिए उपयोगी हैं, लेकिन वे निष्पादन के समय-निर्धारण के लिए पर्याप्त सटीक नहीं हैं। Leader Slot API रूटिंग और ट्रेडिंग निर्णयों के लिए आवश्यक सूक्ष्मता के साथ यह कमी पूरी करता है।
  - [ERPC Leader Slot API दस्तावेज़](https://erpc.global/hi/doc/rpc/leader-slot-api/)
  - [ERPC Web Dashboard](https://dashboard.erpc.global/hi)

[![Validators Solutions - Solana नेटवर्क डेटा](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/)

Solana नेटवर्क डेटा: [Validators Solutions](https://validators.solutions/)

## Q. मैं शून्य-ब्लॉक (zero-slot) ट्रेडिंग कैसे प्राप्त कर सकता हूँ?

शून्य-ब्लॉक (zero-slot) ट्रेडिंग को सफलतापूर्वक प्राप्त करने के लिए अधिक परिष्कृत रणनीतियों की आवश्यकता होती है, इस प्रकार:

- **अवसर क्षेत्रों की पहचान करना**: Solana validator विश्व भर में वितरित हैं, और हर slot के लिए इष्टतम विलंबता हासिल करना भौतिक रूप से असंभव है। इसलिए, जिस क्षेत्र में आपका बुनियादी ढांचा स्थित है वहाँ validator leader schedules की निगरानी करें और सबसे अनुकूल अवसर क्षेत्रों की पहचान करें। कई क्षेत्रों में बुनियादी ढांचे को तैनात करना भी फायदेमंद हो सकता है। उदाहरण के लिए, Frankfurt अपने उच्च validator घनत्व के कारण एक प्रमुख क्षेत्र है, जिसके परिणामस्वरूप अधिक बार leader चयन और अधिक ट्रेडिंग अवसर होते हैं।

  सार्वजनिक मानचित्र-शैली डेटा स्रोतों या मूल RPC API की तुलना में कहीं अधिक सटीकता के साथ आगामी leader schedule, वर्तमान epoch का stake weight, validators का अनुमानित भू-स्थान डेटा और संदर्भ पिंग मान देखने के लिए **ERPC Leader Slot API (`getLeaderSlots`)** का उपयोग करें। इससे आप slots के आने से पहले ही अवसर क्षेत्रों को चिह्नित कर सकते हैं और लगभग शून्य विलंबता वाले ट्रेड निष्पादित कर सकते हैं।
  - [ERPC Leader Slot API दस्तावेज़](https://erpc.global/hi/doc/rpc/leader-slot-api/)
  - [ERPC Web Dashboard](https://dashboard.erpc.global/hi)

- **समर्पित नोड्स तैनात करना**: यदि आप प्रतिस्पर्धा में पीछे रह जाते हैं, तो समर्पित नोड्स तैनात करने पर विचार करें। साझा नोड्स में अन्य उपयोगकर्ताओं के ट्रैफ़िक के कारण विलंबता आती है, इसलिए उनकी अनुशंसा नहीं की जाती। इसके अलावा, अपने समर्पित नोड को अपने एप्लिकेशन वाले नेटवर्क के भीतर ही रखने से नेटवर्क विलंबता काफी कम हो जाती है और प्रदर्शन अनुकूलित होता है।

## Q. क्या मैं किसी विशिष्ट endpoint का उपयोग कर सकता हूँ?

कम-विलंबता वातावरण बनाए रखने के लिए, हमारी प्रणाली स्वचालित रूप से निकटतम उपलब्ध नोड का चयन करती है। यदि आप किसी विशिष्ट endpoint का उपयोग करना चाहते हैं, तो हम उस endpoint के निकटतम स्थित सर्वर को किराए पर लेने की सलाह देते हैं।

## Q. मुझे 401 त्रुटि मिल रही है। क्यों?

कम-विलंबता वातावरण बनाए रखने के लिए, हम IP प्रतिबंध लागू करते हैं। यदि आपके पास कोई subscription नहीं है या आपका IP पंजीकृत नहीं है, तो आपको 401 त्रुटि मिलेगी।

कृपया दोबारा जाँच लें कि आपका पंजीकृत IP आपके वर्तमान पहुँच IP से मेल खाता है या नहीं।

## Q. मुझे 429 त्रुटि मिल रही है। क्यों?

आप अपनी योजना की कनेक्शन सीमा तक पहुँच गए हैं।

यदि आप इस त्रुटि का सामना करते हैं, तो अपनी योजना को अपग्रेड करने पर विचार करें। यदि आपको हमारी प्रीमियम योजना द्वारा प्रदान की जाने वाली तुलना में अधिक कनेक्शन की आवश्यकता है, तो एक समर्पित gRPC node अधिक उपयुक्त होगा।

## Q. समर्पित endpoints तेज़ क्यों हैं?

साझा endpoints का उपयोग कई ग्राहक करते हैं जो समान संसाधन साझा करते हैं। जैसे-जैसे ट्रैफ़िक बढ़ता है, विलंबता होने लगती है। सर्वर संसाधनों की भौतिक सीमाएँ होती हैं, और वे जितना काम संभाल सकते हैं वह सीमित है। जब बहुत सारे अनुरोध एक ही समय में आते हैं, तो उन्हें क्रमिक रूप से संसाधित किया जाना चाहिए, जिससे प्रतिक्रिया समय धीमा हो जाता है।

हालाँकि हम साझा endpoints पर भी प्रदर्शन को अनुकूलित करने के लिए विभिन्न उपाय करते हैं, समर्पित endpoints के साथ आप संसाधन के एकमात्र उपयोगकर्ता होते हैं। इसका मतलब है कि आप अन्य उपयोगकर्ताओं से पूरी तरह अप्रभावित रहते हैं, जो लगातार स्थिर और तेज़ प्रतिक्रियाएँ सुनिश्चित करता है।

इसके अलावा, समर्पित endpoints बिना TLS के संचार विकल्प प्रदान करते हैं, जैसे HTTP। TLS हैंडशेक (लगभग 20ms) को छोड़ देने से, HTTPS की तुलना में संचार और भी तेज़ हो जाता है।

## Q. क्या मेरे subscription लेने के बाद बिक्री मूल्य बढ़ाया जाएगा?

जब तक आपका subscription सक्रिय रहता है, साइनअप के समय आपके द्वारा लॉक किया गया बिक्री मूल्य प्रभावी रहता है। Solana के वास्तविक समय के वर्कलोड को झेल पाने वाले वातावरण वैश्विक स्तर पर दुर्लभ हैं, और हम बढ़ती हार्डवेयर और नेटवर्क मांग के अनुरूप मूल्यों को बढ़ाने की योजना बना रहे हैं। उच्च-स्पेक कॉन्फ़िगरेशन और उच्च-मांग वाले क्षेत्र सबसे तेज़ी से बिकते हैं, इसलिए वर्तमान मूल्य को लॉक करना लंबे समय में सबसे अधिक लागत-कुशल विकल्प है।

## Q. मैं crypto से भुगतान करना चाहता हूँ

यदि आपके पंजीकृत बिलिंग पते का देश EU के सदस्य देशों में से एक है, तो ERPC Web Dashboard से crypto भुगतान उपलब्ध है। यदि आपके account में registered सभी payment cards EU के बाहर issued हैं, तो crypto भुगतान उपलब्ध नहीं है। आप SOL, USDC या EURC से ERPC Credits खरीद सकते हैं।

इन ERPC Credits से ERPC प्लान शुरू करें या जारी रखें। Dashboard खोलें, crypto भुगतान चुनें, अपने wallet से transfer भेजें, और dashboard transaction को सत्यापित करके credits आपके account में जोड़ देगा।

समर्थित देश: आयरलैंड, इटली, एस्टोनिया, ऑस्ट्रिया, क्रोएशिया, चेकिया, जर्मनी, डेनमार्क, नीदरलैंड, पुर्तगाल, पोलैंड, फ़िनलैंड, फ़्रांस, बुल्गारिया, बेल्जियम, माल्टा, यूनान, रोमानिया, लग्ज़मबर्ग, लातविया, लिथुआनिया, साइप्रस, स्पेन, स्लोवाकिया, स्लोवेनिया, स्वीडन, हंगरी।

जो देश इस सूची में नहीं हैं, उनके लिए कृपया क्रेडिट कार्ड से भुगतान करें।

[ERPC Web Dashboard](https://dashboard.erpc.global/hi)

## Q. मैं सबसे कम संभव विलंबता कैसे प्राप्त कर सकता हूँ?

हम एक समर्पित gRPC node को हमारे [Bare-Metal सर्वर](https://erpc.global/hi/baremetal/) के साथ संयोजित करने की अत्यधिक सलाह देते हैं।

दोनों ही समान नेटवर्क साझा करते हैं, जो इंटरनेट को पार किए बिना निजी, शून्य-दूरी संचार की अनुमति देता है। यह सेटअप बेहद कम विलंबता प्राप्त करता है, आम तौर पर लगभग 0.1ms पिंग।

आगे के विवरण के लिए कृपया ERPC Web Dashboard के माध्यम से हमसे संपर्क करें।

[ERPC Web Dashboard](https://dashboard.erpc.global/hi)

🔗 [ERPC Web Dashboard](https://dashboard.erpc.global/hi)

## Q. विलंबता कैसी है?

विलंबता माप विधि और आपके विशिष्ट उपयोग वातावरण के आधार पर भिन्न होती है। सटीक संख्यात्मक मूल्यों पर ध्यान केंद्रित करने के बजाय, यह सुनिश्चित करना महत्वपूर्ण है कि विलंबता आपकी वास्तविक परिचालन आवश्यकताओं को पूरा करती है।

हम विलंबता मापने के लिए TypeScript और Rust में उपयोग में आसान उपकरण प्रदान करते हैं।

- [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream)
- [SLV (हिन्दी)](https://slv.dev/hi)

## Q. क्या यह RPC (gRPC, Shreds) दूसरों की तुलना में तेज़ है?

हम हर मूल्य स्तर की सेवा गति को ध्यान में रखकर बनाते हैं, और किसी भी अन्य प्रदाता के साथ उसकी आमने-सामने तुलना का स्वागत करते हैं। परिणाम क्षेत्र, साझा या समर्पित endpoint के उपयोग, प्रयुक्त प्रोटोकॉल (WebSockets, gRPC या Shreds) और आपके क्लाइंट की प्रोग्रामिंग भाषा के अनुसार बदल सकते हैं।

यदि आपको हमारी सेवा धीमी लगती है, तो कृपया ERPC Web Dashboard के माध्यम से हमें बताएँ कि आपने किन परिस्थितियों में और किन प्रतियोगियों से तुलना की है। हम कारण की पहचान करेंगे और गति में और सुधार करेंगे।

[ERPC Web Dashboard](https://dashboard.erpc.global/hi)

## Q. कौन-सा प्लान सबसे तेज़ प्रदर्शन प्रदान करता है?

आम तौर पर, हमारा उच्चतम-स्तरीय प्लान बेहतर CPU, उच्च मेमोरी क्षमता और मज़बूत हार्डवेयर कॉन्फ़िगरेशन के कारण सबसे तेज़ प्रदर्शन प्रदान करता है।

यदि आपको और भी अधिक शक्तिशाली सर्वरों की आवश्यकता हो, तो हम अनुकूलित समाधान भी प्रदान करते हैं, लेकिन हमारे मानक प्लान इष्टतम मूल्य-से-प्रदर्शन अनुपात देने के लिए डिज़ाइन किए गए हैं।

हमें विश्वास है कि हम हर मूल्य स्तर पर विश्व-स्तरीय प्रदर्शन देते हैं। यदि आपको समान मूल्य सीमा के भीतर कोई तेज़ प्रदाता मिलता है, तो कृपया हमें बताएँ ताकि हम जाँच कर सकें और सुधार कर सकें।

## Q. मुझे उच्च विलंबता का अनुभव हो रहा है। मैं क्या कर सकता हूँ?

विलंबता काफी हद तक endpoint के प्रति आपकी निकटता पर निर्भर करती है। हम प्रदान किए गए endpoint के पास के सर्वर से एक्सेस करने की सलाह देते हैं। सबसे तेज़ कनेक्शन हमारे [Bare-Metal सर्वर](https://erpc.global/hi/baremetal/) और [VPS सेवा](https://erpc.global/hi/vps/) के साथ प्राप्त किए जाते हैं।

## Q. सबसे तेज़ कौन-सा है: WebSockets, gRPC या Shreds?

हमारे ग्राहकों की प्रतिक्रिया लगातार गति को निम्नानुसार रैंक करती है:

**Shreds > gRPC > WebSockets**

यदि आप भिन्न परिणाम देखते हैं तो कृपया अपना अनुभव साझा करें।

## Q. विलंबता वैसी नहीं है जैसी मैंने उम्मीद की थी।

प्रदर्शन उपयोग की गई प्रोग्रामिंग भाषा के आधार पर भिन्न होता है। आम तौर पर, भाषा गति की रैंक:

**Rust > Go > TypeScript (JavaScript) > Python**

विस्तृत तुलना के लिए देखें:

[प्रोग्रामिंग भाषा स्पीड तुलना](https://niklas-heer.github.io/speed-comparison/)

अधिकतम प्रदर्शन के लिए, हम दृढ़ता से Rust का उपयोग करने की सलाह देते हैं।