---
title: "Solana SWQoS endpoint दस्तावेज़"
description: "Solana SWQoS (Stake weighted Quality of Service) Endpoint का परिचय और उपयोग"
canonical: "https://erpc.global/hi/doc/rpc/swqos-endpoint/"
locale: "hi"
---

# Solana SWQoS endpoint दस्तावेज़

## SWQoS Endpoint क्या है?

ERPC का **SWQoS Endpoint** एक high-performance RPC सेवा है, जो stake connections वाले users को dedicated lanes के ज़रिए transactions भेजने देती है।  
यह shared और dedicated, दोनों plans के लिए उपलब्ध है, जिससे transactions तेज़ और ज़्यादा भरोसेमंद ढंग से पहुँचते हैं।

यह endpoint ERPC Web Dashboard पर अपनी elSOL holdings register करके प्राप्त किया जा सकता है।

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

## SWQoS क्या है?

**SWQoS (Stake weighted Quality of Service)** एक communication control तंत्र है, जो stake connections वाले validators को प्राथमिकता देता है।  
Leaders कुल bandwidth का लगभग **80% priority lane को** और **20% non-priority lane को** आवंटित करते हैं।

Stake connections वाला traffic priority lane का इस्तेमाल कर सकता है और साथ ही non-priority lane से भी भेजा जा सकता है। इसलिए, सिर्फ़ non-priority lane पर निर्भर traffic की तुलना में **प्रभावी delivery क्षमता काफ़ी ज़्यादा होती है**।  
यह नियंत्रण **Priority fee की प्रक्रिया से पहले** लागू होता है, उस चरण पर जहाँ traffic स्वीकार होकर leader की ओर route किया जाता है; यानी कोई transaction priority lane तक पहुँचता है या नहीं, इसका सीधा असर आगे की processing की गति पर पड़ता है।

## Priority Fee से संबंध

Priority fee की अहम भूमिका है, लेकिन यह **transaction के SWQoS routing से leader तक पहुँचने के बाद** लागू होती है।  
अगर कोई transaction SWQoS priority lane में प्रवेश नहीं कर पाता, तो Priority fees का असर सीमित हो जाता है, और बुनियादी पहुँच (reachability) सुधारना मुश्किल होता है।  
सबसे अच्छे संचालन के लिए, **SWQoS पर आधारित reachability को उपयुक्त Priority fee सेटिंग्स के साथ जोड़ना** सबसे प्रभावी है।

## लागत संरचना में बदलाव

पारंपरिक transaction submission सेवाओं में, users को transactions भेजते समय **Tips** जोड़ने पड़ते थे।  
ERPC के SWQoS Endpoint के साथ Tips की ज़रूरत नहीं है। इसके बजाय, priority bandwidth तक पहुँच **elSOL रखने** से मिलती है।

**elSOL**, Solana पर SOL को stake करके जारी किया जाने वाला एक **Liquid Staking Token (LST)** है।  
SOL के मुकाबले इसकी विनिमय दर जमा हुए staking rewards को दर्शाती है और 1:1 के अनुपात पर तय नहीं होती।

elSOL को unstaking प्रक्रिया से वापस SOL में बदला जा सकता है, और settlement में जमा हुए staking rewards शामिल होते हैं।

elSOL के ज़रिए stake किया गया SOL, ERPC से जुड़े validators को delegate किया जाता है।  
जैसे-जैसे elSOL holdings बढ़ती हैं, पूरे ERPC में उपलब्ध कुल SWQoS bandwidth बढ़ती जाती है।  
elSOL रखकर users सीधे नेटवर्क को मज़बूत करने में योगदान देते हैं, और बदले में dedicated transmission lanes तक पहुँच पाते हैं।

- elSOL आधिकारिक साइट: https://elsol.app/hi

## Bandwidth आवंटन (TPS संरचना)

Shared SWQoS Endpoints पर पात्र users को connected wallet में रखे गए **हर 4.2 elSOL पर 1 TPS** मिलता है, जिसे नीचे की ओर पूर्णांकित किया जाता है। उदाहरण के लिए, connected wallet में 10 elSOL रखने पर **2 TPS** मिलते हैं।

वास्तव में उपलब्ध TPS, ERPC plan की अधिकतम सीमा और elSOL-आधारित आवंटन में से जो कम हो, उससे तय होता है।

Developer Plan+ और Bundle Plans सहित पात्र ERPC shared plans, dashboard द्वारा elSOL वाले wallet की पुष्टि हो जाने के बाद shared SWQoS आवंटन का इस्तेमाल कर सकते हैं।

Dedicated RPC nodes के लिए SWQoS एक **+€100/माह** option के रूप में उपलब्ध है, जो dedicated node को **1,000 SOL का staking आवंटन** देता है।

सेटअप और verification ERPC Dashboard में होते हैं: https://dashboard.erpc.global

## Connection को warm रखना (Keep Alive)

ERPC के Solana SWQoS endpoint पर `/ping` को GET request भेजकर आप **client और ERPC SWQoS endpoint के बीच HTTPS connection बनाए रख सकते हैं**।

Transaction भेजते समय, पहले request में HTTPS और TLS session स्थापित करने में थोड़ा समय लगता है।  
पहले से `/ping` भेजकर और इस connection को सक्रिय रखकर, असली transaction भेजते समय आप **शुरुआती connection विलंबता से बच सकते हैं और तुरंत transaction submission शुरू कर सकते हैं**।

भले ही transactions लगातार न भेजे जाएँ, यह तरीका उन setups के लिए प्रभावी है जहाँ खास पलों पर transactions जल्दी भेजने होते हैं, और यह शुरुआती submission के व्यवहार को स्थिर रखने में मदद करता है।

## पिंग एंडपॉइंट

Keep Warming के लिए SWQoS endpoint पर `/ping` को GET request भेजी जाती है।  
यह request किसी transaction को process नहीं करती और इसका इस्तेमाल केवल client और ERPC के बीच connection की स्थिति बनाए रखने के लिए होता है।

### Endpoint का फ़ॉर्मेट (HTTPS)

```text
https://<your-swqos-endpoint-domain>/ping
```

`<your-swqos-endpoint-domain>` को ERPC द्वारा दिए गए SWQoS-विशिष्ट domain से बदलें।

## उपयोग का उदाहरण

### नियमित Keep Alive का उदाहरण (JavaScript)

```ts
async function keepWarm(endpoint: string) {
  try {
    await fetch(`${endpoint}/ping`, { method: 'GET' })
  } catch {
    // Ignore failures
  }
}

setInterval(() => {
  keepWarm('https://<your-swqos-endpoint-domain>')
}, 30000)
```

नियमित अंतराल पर `/ping` भेजकर आप ऐसी स्थिति बनाए रख सकते हैं जिसमें **ज़रूरत पड़ते ही transaction submission तुरंत शुरू हो सके**।

## नोट्स

・`/ping` न TPS खर्च करता है और न ही elSOL-आधारित bandwidth की गणना को प्रभावित करता है
・यह transaction submission का विकल्प नहीं है
・यह एक पूरक request है, जिसका इस्तेमाल केवल client से ERPC तक के connection को बनाए रखने के लिए होता है

SWQoS (stake-based routing) और Priority fees का डिज़ाइन पहले जैसा ही रहता है।
Keep Warming को **transaction submission शुरू होने के समय विलंबता घटाने** के तंत्र के रूप में इस्तेमाल करें।