--- title: "FAQ - Geyser gRPC Stream" description: "Veelgestelde vragen over de ERPC - Enhanced Solana RPC Geyser gRPC Stream" canonical: "https://erpc.global/nl/faq/grpc/general/" locale: "nl" --- # FAQ - Geyser gRPC Stream ## V. In welke regio's bevinden zich uw nodes? We beheren momenteel nodes in de volgende regio's: - Frankfurt (FRA) - Amsterdam (AMS) - Londen (LON) - New York (NY) - Tokyo (TY) - Singapore (SGP) - Sydney (SYD) ERPC meet de werkelijke netwerklatentie op basis van echte routeringspaden en selecteert automatisch de regio met de laagste latentie, in plaats van uit te gaan van de hemelsbrede afstand. Deze aanpak verbetert niet alleen de latentie voor individuele gebruikers, maar verhoogt ook de algehele netwerkefficiëntie en versterkt de wereldwijde weerbaarheid van ERPC tegen potentiële aanvallen. Als uw omgeving niet automatisch de optimale regio selecteert, neem dan contact met ons op via het ERPC Web Dashboard. ERPC Web Dashboard: https://dashboard.erpc.global/nl ## V. De latentie geeft 9999ms aan en er wordt een niet-optimale regio geselecteerd. Wat moet ik doen? Voor de regioselectie van gRPC verstuurt ERPC ICMP-latentieprobes naar uw geregistreerde IP-adres vanaf de hieronder vermelde proxyhosts. Sta inkomende ICMP-echoverzoeken toe vanaf elk vermeld bron-IP-adres. Als deze worden geblokkeerd door een firewall (ufw, cloudfirewall, beveiligingsgroep enz.), kan de meting `9999ms` worden en kan een niet-optimale regio worden geselecteerd. Meerdere IP-adressen binnen één regio zijn afzonderlijke probehosts; ze zijn allemaal vereist. [ERPC_PING_SOURCES:grpc]: # | Regio | ICMP-bron-IP-adressen | | --- | --- | | 🇳🇱 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` | ## V. Ik heb mijn IP toegestaan, maar kan nog steeds niet verbinden. Wat moet ik controleren? Gebruik het versleutelde HTTPS-endpoint dat in het Dashboard is geselecteerd. HTTPS gebruikt poort 443; HTTP op poort 80 blijft de onversleutelde optie met lage latentie. Beide transporten gebruiken dezelfde allowlist voor geregistreerde IP’s. Gebruik het geselecteerde Dashboard-endpoint: HTTPS op 443 of HTTP op 80. - HTTPS-endpoint: gebruik het in het Dashboard geselecteerde endpoint op poort 443. - HTTP-endpoint: gebruik het in het Dashboard geselecteerde endpoint op poort 80. - Gebruik de URL uit het Dashboard met `https://` of `http://`. Authenticatie gebeurt op basis van uw geregistreerde IP-adres. Voeg geen `x-token`-, `token`- of `Authorization`-headers toe tenzij een specifieke productpagina dit expliciet vermeldt. ## V. Ik heb alleen WebSocket gebruikt. Kan ik gRPC gebruiken? Heeft u voorbeelden? Ja. U kunt snel testen en beginnen met ontwikkelen met gRPC met behulp van SLV. Voor een gedeeld endpoint dat u zonder token kunt testen, voert u uit: ```bash slv check grpc --endpoint --token none ``` Bekijk onze [Snelstarthandleiding voor gRPC](https://slv.dev/nl/doc/geyser-grpc/quickstart/) voor details. ## V. Kan ik twee IP-adressen registreren? U kunt één endpoint per abonnement gebruiken. Als u twee IP-adressen wilt gebruiken, moet u twee afzonderlijke abonnementen afsluiten. ## V. Zijn er filterbeperkingen? Shared Geyser gRPC gebruikt fair-usebescherming zodat één stream niet de resources verbruikt die andere ERPC-klanten nodig hebben. Volgens de huidige Shared-regel wordt elke niet-lege `blocks`-map afgewezen, ook een beperkte blokaanvraag. Elk accountfilter moet `account`, `owner` of een ondersteund cuckoo-filter bevatten; alleen `memcmp` of `dataSize` is niet voldoende. Verwijder een afgewezen vorm en abonneer u alleen op de gegevens die uw applicatie nodig heeft. Een transactie-abonnement of blokmetadata kan aan de behoefte voldoen zonder een volledig blok te vervoeren. Dedicated Geyser gRPC is passend wanneer een legitieme workload de Shared-limiet voor vorm of resources overschrijdt; het maakt ongeldige parameters niet geldig en herstelt geen trage client. ## V. Hoe verzamel ik een gRPC-fout voordat ik opnieuw verbind? Bewaar de eerste fout voordat een reconnect-lus deze vervangt. Leg de gRPC-status en het bericht uit initiële metadata en trailers vast, samen met `x-erpc-error-code`, `x-erpc-error-reason` en `x-erpc-doc-url`. Wanneer ERPC een pauze opgeeft, leg ook `x-erpc-retry-after-seconds` en `x-erpc-retry-at` (Unix-seconden) vast. Een fout kan worden weergegeven als `ERPC [STREAM_GUARD_SLOW_READER]: ...`. Plak de getoonde fout of de code in de FAQ-zoekfunctie. De canonieke uitleg staat in de [ERPC gRPC-FAQ](https://erpc.global/nl/faq/grpc/general/). Ga er niet van uit dat een trailer aankomt wanneer een verbinding vroeg eindigt. U kunt ook op een symptoom zoeken: trage ontvanger, verbroken, bandbreedte, afleververtraging, backlog, pauze, opnieuw proberen, ongeldig argument, resource uitgeput, toestemming geweigerd, IP-registratie, te veel streams, volledige blokken of alle accounts. ## V. Welke gRPC-fouten pauzeren mijn verbinding, en wanneer moet mijn client stoppen met opnieuw verbinden? Een pauze is een getimede periode die ERPC na bepaalde fouten instelt. Zolang die loopt, mag de client niet opnieuw verbinden. **Wat geteld wordt.** Deze fouten worden geteld en delen één reeks treden: - Elke Subscribe-aanvraag die ERPC afwijst met `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` of `STREAM_GUARD_SHAPE_ACCOUNTS_ALL`, de eerste inbegrepen. De eerste getelde fout is de waarschuwing, die geen pauze start. - `STREAM_GUARD_SLOW_READER`. Uitzondering: als de afleververtraging aan de kant van ERPC ontstaat, sluit ERPC de stream zonder die te tellen, en bevat de fout geen retry-deadline. Deze worden niet geteld: het opnieuw verbinden zelf, de vier codes `STREAM_ADMISSION_*` (`STREAM_ADMISSION_LIMIT_REACHED`, `STREAM_ADMISSION_IP_NOT_ADMITTED`, `STREAM_ADMISSION_SOURCE_UNAVAILABLE` en `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE`) en elke getelde fout die optreedt terwijl een pauze loopt. Een getelde fout tijdens een pauze verlengt de pauze niet en gaat niet naar de volgende trede. **De treden.** Elke getelde fout gaat één trede verder in deze volgorde, te beginnen met de waarschuwing: - Waarschuwing: geen pauze. - Pauze van 60 seconden. - Pauze van 300 seconden. - Pauze van 1800 seconden. - Pauze van 86400 seconden (24 uur). Dit is de laatste trede: daarop start elke getelde fout nog een pauze van 86400 seconden. Op de waarschuwingstrede gaat de volgende getelde fout alleen naar de pauze van 60 seconden wanneer die binnen 1 uur na de waarschuwing komt. Een getelde fout die meer dan 1 uur na de waarschuwing komt, is nog een waarschuwing zonder pauze, en het venster van 1 uur loopt dan vanaf die nieuwe waarschuwing. Een getelde fout die minder dan 60 seconden na de laatste getelde fout komt, telt als deel van die fout en gaat geen trede verder. **Wanneer de treden teruggaan naar de waarschuwing.** Zodra de treden een pauze hebben gestart, gaan ze pas terug naar de waarschuwing na 24 uur zonder getelde fout en zonder pauze, gemeten vanaf het einde van de laatste pauze; de volgende getelde fout daarna is een waarschuwing zonder pauze. Tot die tijd start de volgende getelde fout onmiddellijk de volgende trede, zonder waarschuwing. **De egress-pauze.** `STREAM_GUARD_EGRESS_BUDGET` start een eigen vaste pauze van 600 seconden. Deze fout laat de treden niet oplopen. **Waar de eindtijd staat.** - De fout die een pauze start, bevat `Retry after N seconds.` en de headers `x-erpc-retry-after-seconds` en `x-erpc-retry-at` (Unix-seconden). De waarschuwing bevat geen retry-deadline. - Wanneer een getelde afgewezen aanvraag degene is die een pauze start, komt die terug als `STREAM_GUARD_SHAPE_REJECT_PENALTY` met `ResourceExhausted (8)` in plaats van met de eigen code. - Tijdens een pauze wegens een trage lezer of egress krijgt een poging om opnieuw te verbinden `STREAM_GUARD_PENALTY_ACTIVE` met de resterende tijd. - Tijdens een pauze die door een afgewezen aanvraag is gestart, wordt een nieuwe verbinding onmiddellijk gesloten, zonder gRPC-status en zonder ERPC-code. Een aanvraag op een verbinding die nog open is, kan nogmaals met `STREAM_GUARD_SHAPE_REJECT_PENALTY` en de resterende tijd worden beantwoord voordat die verbinding wordt gesloten. De client ziet de eindtijd mogelijk nooit meer, dus moet hij `x-erpc-retry-at` opslaan uit de eerste fout die deze header bevat. | Code | gRPC-status | Start dit een pauze of laat het de treden oplopen? | Wat de client moet doen | | --- | --- | --- | --- | | `ERPC_GRPC_INVALID_ARGUMENT` | `InvalidArgument (3)` | Ja, wanneer het een Subscribe-aanvraag afwijst. Het is dan een getelde fout volgens de treden hierboven. | Stop de lus en verstuur dezelfde aanvraag niet opnieuw. De eigen vraag hieronder noemt wat u moet controleren. | | `STREAM_GUARD_SHAPE_BLOCKS` | `PermissionDenied (7)` | Ja. Het is een getelde fout volgens de treden hierboven. | Stop de lus en verstuur dezelfde aanvraag niet opnieuw. De eigen vraag hieronder noemt wat u moet controleren. | | `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` | `PermissionDenied (7)` | Ja. Het is een getelde fout volgens de treden hierboven. | Stop de lus en verstuur dezelfde aanvraag niet opnieuw. De eigen vraag hieronder noemt wat u moet controleren. | | `STREAM_GUARD_SLOW_READER` | `ResourceExhausted (8)` | Ja. Het is een getelde fout volgens de treden hierboven. Uitzondering: als de afleververtraging aan de kant van ERPC ontstaat, sluit ERPC de stream zonder die te tellen, en bevat de fout geen retry-deadline. | Stop de lus. De eigen vraag hieronder noemt wat u moet controleren. Als deze fout een pauze heeft gestart, verbind dan niet opnieuw vóór de tijd in `x-erpc-retry-at`. | | `STREAM_GUARD_EGRESS_BUDGET` | `ResourceExhausted (8)` | Ja. Het start een vaste pauze van 600 seconden buiten de treden hierboven. | Verbind niet opnieuw vóór de tijd in `x-erpc-retry-at`. De eigen vraag hieronder noemt wat u moet controleren. | | `STREAM_GUARD_SHAPE_REJECT_PENALTY` | `ResourceExhausted (8)` | Ja. Het is de getelde afgewezen aanvraag die een pauze heeft gestart. Het kan op een verbinding die nog open is, nogmaals met de resterende tijd terugkomen. | Verbind niet opnieuw vóór de tijd in `x-erpc-retry-at`. Herstel de afgewezen aanvraag en verstuur die niet ongewijzigd opnieuw. | | `STREAM_GUARD_PENALTY_ACTIVE` | `ResourceExhausted (8)` | Nee. Het meldt een al lopende pauze wegens een trage lezer of egress. | Verbind niet opnieuw vóór de tijd in `x-erpc-retry-at`. | | `STREAM_ADMISSION_LIMIT_REACHED` | `ResourceExhausted (8)` | Nee. Het heeft geen getimede pauze. | Sluit ongebruikte streams en probeer het daarna opnieuw. | | `STREAM_ADMISSION_IP_NOT_ADMITTED` | `PermissionDenied (7)` | Nee. Het heeft geen getimede pauze. | De eigen vraag hieronder noemt wat u moet controleren. | | `STREAM_ADMISSION_SOURCE_UNAVAILABLE` | `Unavailable (14)` | Nee. Het heeft geen getimede pauze. | Pas zoals gebruikelijk backoff toe en probeer het na een wachttijd opnieuw. | | `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` | `Unavailable (14)` | Nee. Het heeft geen getimede pauze. | Pas zoals gebruikelijk backoff toe en probeer het na een wachttijd opnieuw. | **Wat de client moet doen.** Stop bij een getelde fout de lus, verstuur dezelfde aanvraag niet opnieuw en herstel die. Verbind tijdens een pauze niet opnieuw vóór de tijd in `x-erpc-retry-at`. Afgewezen Subscribe-aanvragen worden geteld volgens de regels hierboven, opnieuw verbinden niet. ## V. Wat betekent `STREAM_GUARD_SLOW_READER` met `ResourceExhausted (8)` wanneer de verbinding van een trage ontvanger wordt verbroken? ERPC zag voor deze stream onvoldoende schrijfvoortgang of afleververtraging. Alleen afleververtraging bepaalt de oorzaak niet. Controleer netwerkverlies, effectieve bandbreedte, hostcapaciteit en of de applicatieconsument bijhoudt. Beperk de geabonneerde gegevens en verplaats verwerking uit de ontvangstlus naar een begrensde wachtrij. Een begrensde wachtrij regelt geheugengebruik, maar kan een aanhoudend trage consument niet oplossen. Wacht op een door ERPC opgegeven retry-deadline voordat u opnieuw verbindt. De vraag “Waarom blijft mijn gRPC-stream op een vaste snelheid steken en raakt hij achterop?” hieronder legt het ontvangstvenster uit en hoe u het in uw clientlibrary vergroot. ## V. Waarom blijft mijn gRPC-stream op een vaste snelheid steken en raakt hij achterop? Een klein ontvangstvenster in uw client, of in iets tussen uw client en ERPC, kan leiden tot afsluitingen met `STREAM_GUARD_SLOW_READER` en de pauzes die daarop volgen. Dit antwoord legt uit wat een ontvangstvenster is, hoe u nagaat of het uw stream beperkt en hoe u het per library vergroot. De vraag “Welke gRPC-fouten pauzeren mijn verbinding, en wanneer moet mijn client stoppen met opnieuw verbinden?” hierboven geeft de treden en hun duur. **Wat een ontvangstvenster is.** In HTTP/2 laat de ontvanger de verzender weten hoeveel gegevens er verstuurd mogen worden voordat de ontvanger de ontvangst bevestigt; die hoeveelheid is het ontvangstvenster (het HTTP/2-flow-controlvenster). Eén round trip vervoert hoogstens één venster, dus de maximale snelheid ligt rond het venster gedeeld door de round-trip time (de tijd naar het endpoint en terug). **De andere grenzen.** Er zijn twee vensters, één per stream en één per verbinding (alle streams op een verbinding delen dat venster), en het kleinere van de twee bepaalt de grens. Volgens de HTTP/2-specificatie beginnen beide vensters op 65.535 bytes. De TCP-ontvangstbuffer (geheugen voor binnenkomende gegevens) beperkt de snelheid op dezelfde manier. Een proxy, load balancer, gateway, VPN of sidecar daartussen heeft eigen vensters en buffers. Een klein venster of een kleine buffer daar begrenst de stream, ook als de vensters van uw eigen client groot zijn. **Hoe het eruitziet.** Eén stream blijft op bijna dezelfde snelheid steken, hoe druk het ook is op de chain, en zijn afleververtraging groeit gestaag. ERPC heeft gemeten vanaf een plek met een round-trip time van ongeveer 6 ms naar het gedeelde endpoint in Frankfurt, en veranderde tussen de metingen alleen het venster: - Streamvenster van 16 KiB: vlak rond 2,7 MB/s (16 KiB gedeeld door 6 ms); de afleververtraging groeide met ongeveer 0,6 seconden per seconde en bereikte 26 seconden in 45 seconden. - Beide vensters op 16 MiB: de maximale afleververtraging was 14 ms. Als de afleververtraging aan de kant van ERPC ontstaat, sluit ERPC de stream zonder die te tellen, en bevat de fout geen retry-deadline. **Controleer het.** 1. Vergelijk de snelheid en de afleververtraging van de stream met het patroon hierboven. 2. Meet de round-trip time. Vermenigvuldig de snelheid van de stream met de round-trip time om het venster te schatten (2,7 MB/s maal 6 ms is ongeveer 16 KB). 3. Controleer of een van de twee vensters van uw client een kleine waarde heeft, of dat automatische groei (de library vergroot het venster zelf) is uitgeschakeld. 4. Controleer de TCP-ontvangstbuffer. Voer op Linux `sysctl net.ipv4.tcp_rmem net.core.rmem_max` uit en kijk of uw applicatie `SO_RCVBUF` instelt, wat de automatische afstemming van de buffergrootte uitschakelt. 5. Controleer de vensters en buffers van alles wat daartussen zit. 6. Als de snelheid geen plafond heeft en alleen de vertraging groeit, is de verwerking na ontvangst traag. De vraag “Wat betekent `STREAM_GUARD_SLOW_READER` met `ResourceExhausted (8)` wanneer de verbinding van een trage ontvanger wordt verbroken?” hierboven legt uit hoe u de ontvangstlus beperkt tot lezen en zwaar werk naar een begrensde wachtrij verplaatst. **Instellingen per library.** De voorbeelden zetten beide vensters op 16 MiB, zoals in de meting van ERPC. Zoek bij een library die hier niet staat naar instellingen voor het initiële HTTP/2-venster. **Rust, `yellowstone-grpc-client`.** Zonder vensterinstellingen gebruikt `GeyserGrpcClient::build_from_shared` 2 MiB per stream en 5 MiB per verbinding. Bij een round trip van 6 ms laten deze standaardwaarden meer dan 300 MB/s toe, dus begrenzen ze de stream niet. Gebruik de twee builder-methoden om de vensters zelf in te stellen, en laat `http2_adaptive_window` uit. Staat die aan, dan begint het venster op 65.535 bytes en groeit het zelf tot 16 MiB, waarbij uw waarden worden genegeerd. ```rust // Beide vensters vast op 16 MiB; laat http2_adaptive_window uit. 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 of later.** Standaardwaarden: 4 MiB per stream, 8 MiB per verbinding, automatische groei aan. Het venster begint op 64 KiB en groeit tot 16 MiB, dus de standaardwaarden begrenzen de stream zelden. Geef het derde argument mee met `grpcHttp2AdaptiveWindow: false` om de groottes vast te zetten. ```typescript // Adaptief venster uit, zodat deze vaste groottes worden gebruikt. const client = new Client(endpoint, undefined, { grpcInitialStreamWindowSize: 16 * 1024 * 1024, grpcInitialConnectionWindowSize: 16 * 1024 * 1024, grpcHttp2AdaptiveWindow: false, }) ``` **TypeScript, `@triton-one/yellowstone-grpc` 5.0.0 of eerder.** Deze versies gebruiken `@grpc/grpc-js`, waarvan het standaardvenster 65.535 bytes is: ongeveer 11 MB/s bij 6 ms, ongeveer 0,66 MB/s bij 100 ms. Vanaf versie 1.14 past `@grpc/grpc-js` de optie `'grpc-node.flow_control_window'` toe op beide vensters; versie 1.13 past die optie alleen toe op het streamvenster, waardoor het verbindingsvenster op 65.535 bytes blijft (ongeveer 11 MB/s bij 6 ms). Met een versie van `@grpc/grpc-js` ouder dan 1.14 is een upgrade naar `@triton-one/yellowstone-grpc` 5.0.1 of later de snellere weg. ```typescript // Vereist @grpc/grpc-js 1.14 of later om beide vensters te vergroten. const client = new Client(endpoint, undefined, { 'grpc-node.flow_control_window': 16 * 1024 * 1024, }) ``` **Go, `google.golang.org/grpc`.** Standaard vergroot de library de vensters zelf, tot 16 MiB. `grpc.WithInitialWindowSize` en `grpc.WithInitialConnWindowSize` zetten ze vast en schakelen de automatische groei uit; waarden onder 64 KiB worden genegeerd. Stel beide in: met maar één ervan blijft het andere venster op 64 KiB. ```go // Stel beide in; dit schakelt ook de automatische venstergroei uit. conn, err := grpc.NewClient(target, grpc.WithTransportCredentials(creds), grpc.WithInitialWindowSize(16<<20), grpc.WithInitialConnWindowSize(16<<20), ) ``` **Python, `grpcio`.** `grpc.http2.bdp_probe` staat standaard aan, dus de vensters groeien zelf; verwijder `("grpc.http2.bdp_probe", 0)` als uw code die meegeeft. `grpc.http2.lookahead_bytes` bepaalt hoeveel er per stream vooruit wordt gelezen (standaard 64 KB); grotere waarden kunnen helpen bij een lange round trip. ```python # Staat ("grpc.http2.bdp_probe", 0) in uw options, verwijder het dan. channel = grpc.secure_channel(target, creds, options=[ ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024), ]) ``` **Dichterbij ontvangen.** Met een kortere round trip levert hetzelfde venster meer op, en met de [VPS-service](https://erpc.global/nl/vps/) en de [Bare-Metal servers](https://erpc.global/nl/baremetal/) van ERPC staat de client dicht bij het endpoint. **Splits met beleid.** Standard staat 10 streams toe en Premium 50, per geregistreerd bron-IP. Elke stream krijgt een eigen streamvenster, maar streams op één verbinding delen één verbindingsvenster, dus een klein verbindingsvenster beperkt de snelheid nog steeds. Sluit bij het vervangen van een stream eerst de oude: open streams tellen mee voor de limiet, en boven de limiet komt `STREAM_ADMISSION_LIMIT_REACHED` terug (de eigen vraag daarover staat hieronder). Splitsen maakt trage verwerking niet sneller. ## V. Wat betekent `STREAM_GUARD_EGRESS_BUDGET` met `ResourceExhausted (8)`? Het totale verkeer van het IP overschreed de Shared-limiet, waardoor gerelateerde streams samen kunnen sluiten. Verminder gegevensvolume en onnodige parallelle streams en wacht tot de teruggegeven deadline. Deze egress-pauze duurt 600 seconden en verhoogt de strafladder niet, al kan een bestaande langere pauze blijven gelden. ## V. Wat betekent `STREAM_GUARD_PENALTY_ACTIVE` met `ResourceExhausted (8)`? Een eerdere pauze wegens een trage lezer of egress loopt nog, en dit antwoord bevat de resterende tijd. Bewaar de eerste ERPC-fout, herstel de oorzaak en verbind niet opnieuw vóór `x-erpc-retry-at`; verbind niet vroeg opnieuw om te testen. Pogingen om opnieuw te verbinden worden niet geteld. De vraag “Welke gRPC-fouten pauzeren mijn verbinding, en wanneer moet mijn client stoppen met opnieuw verbinden?” hierboven geeft de treden en hun duur. ## V. Wat betekent `STREAM_GUARD_SHAPE_BLOCKS` met `PermissionDenied (7)`? De huidige Shared-regel wijst elke niet-lege `blocks`-map af, ook bij een beperkte aanvraag. Verwijder de `blocks`-map. Gebruik transacties en/of blokmetadata wanneer die aan de eis voldoen; geen van beide is gelijk aan een volledig blok. Voor volledige blokken is Dedicated Geyser gRPC nodig; dit betekent niet dat er een Shared-plan met selectieve blokken bestaat. ## V. Wat betekent `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` met `PermissionDenied (7)`? Een accountfilteritem moet gegevens selecteren met `account`, `owner` of een ondersteund cuckoo-filter. `memcmp` en `dataSize` alleen zijn onvoldoende. Beperk de accountaanvraag tot een van deze ondersteunde vormen of gebruik Dedicated Geyser gRPC wanneer een volledige accountstream nodig is. ## V. Wat betekent `STREAM_GUARD_SHAPE_REJECT_PENALTY` met `ResourceExhausted (8)`? Deze code komt terug in plaats van `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` of `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` wanneer die getelde afgewezen aanvraag degene is die een pauze start; de vraag “Welke gRPC-fouten pauzeren mijn verbinding, en wanneer moet mijn client stoppen met opnieuw verbinden?” hierboven legt uit wanneer dat gebeurt. De code bevat `Retry after N seconds.`, `x-erpc-retry-after-seconds` en `x-erpc-retry-at`. Tijdens deze pauze worden nieuwe verbindingen onmiddellijk gesloten, zonder gRPC-status en zonder ERPC-code, dus ziet de client de eindtijd mogelijk nooit meer. Sla `x-erpc-retry-at` op uit de eerste fout die deze header bevat. Afgewezen Subscribe-aanvragen worden geteld volgens de regels hierboven, opnieuw verbinden niet. Herstel de aanvraag en verstuur die niet ongewijzigd opnieuw. Een vroege verbindingssluiting kan op een transportfout lijken; bewaar daarom de eerste ERPC-fout voordat de reconnect-lus deze verbergt. ## V. Wat betekent `STREAM_ADMISSION_LIMIT_REACHED` met `ResourceExhausted (8)`? De toelatingscapaciteit is momenteel vol. Sluit ongebruikte of dubbele streams, controleer de capaciteit voor de verbinding en probeer opnieuw wanneer capaciteit beschikbaar is. Dit antwoord betekent op zichzelf niet dat een getimede straf actief is. ## V. Wat betekent `STREAM_ADMISSION_IP_NOT_ADMITTED` met `PermissionDenied (7)`? ERPC kon de verbinding niet toelaten, ook nadat een respijtperiode voor IP-registratie afloopt. Vergelijk het werkelijke uitgaande IP met het geregistreerde IP en bevestig de huidige toegangsstatus. Laat een registratiewijziging doorwerken zonder een vaste propagatietijd aan te nemen en neem contact op met support als dit aanhoudt. ## V. Wat betekent `STREAM_ADMISSION_SOURCE_UNAVAILABLE` met `Unavailable (14)`? ERPC kon de bron van deze verbinding op dat moment niet bepalen. Pas backoff toe en probeer het later opnieuw. Neem bij aanhouden contact op met support met de eerste fout en metadata; dit antwoord bewijst geen fout in het netwerk of de server van de klant. ## V. Wat betekent `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` met `Unavailable (14)`? ERPC kon de toegang op dat moment niet verifiëren. Pas backoff toe en probeer het later opnieuw; neem contact op met support als het doorgaat. Herhaald opnieuw registreren, filters verruimen of Dedicated Geyser gRPC kopen herstelt dit beschikbaarheidsantwoord niet. ## V. Wat betekent `ERPC_GRPC_INVALID_ARGUMENT` met `InvalidArgument (3)`? De aanvraag bevat ongeldige parameters, opties, veldtypen, sleutels of filtercombinaties. Herstel de aanvraag voordat u opnieuw probeert, en verstuur dezelfde aanvraag niet opnieuw. Elke Subscribe-aanvraag die met deze code wordt afgewezen, is een getelde fout volgens de pauzeregels in de vraag “Welke gRPC-fouten pauzeren mijn verbinding, en wanneer moet mijn client stoppen met opnieuw verbinden?” hierboven, samen met `STREAM_GUARD_SHAPE_BLOCKS`, `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` en `STREAM_GUARD_SLOW_READER`. Wanneer zo'n aanvraag een pauze start, komt die terug als `STREAM_GUARD_SHAPE_REJECT_PENALTY` met `ResourceExhausted (8)`. Dedicated Geyser gRPC maakt ongeldige parameters niet geldig. De foutmelding sluit de code af met `(reason: )`, en dezelfde token staat in de responsheader `x-erpc-error-reason`. Zoek de token hieronder op om te zien wat u moet aanpassen. Waar een limiet geldt, noemt de foutmelding die. | Reden | Wat het betekent | Wat u moet aanpassen | | --- | --- | --- | | `too_many_filters` | De aanvraag bevat meer benoemde filters of data slices dan één aanvraag mag hebben. | Gebruik per aanvraag minder benoemde filters (of data slices) van dit type. | | `empty_filter` | Een filter heeft geen adres, en een leeg filter betekent alles. | Geef elk filter minstens één adres (accounts: een account of owner; transacties: een lijst met accounts). Shared gRPC bedient geen leeg filter. | | `too_many_addresses` | Eén filterveld bevat te veel adressen. | Gebruik minder adressen in één filterveld; verdeel ze over filters of beperk de lijst. | | `address_not_allowed` | Een filter noemt een adres dat Shared gRPC niet toestaat. | Haal dat adres met veel verkeer uit het filter. | | `filter_name_too_long` | Een filternaam is te lang. | Gebruik kortere filternamen (de map-sleutels). | | `invalid_commitment` | Het commitment-niveau is niet geldig. | Gebruik `processed`, `confirmed` of `finalized`. | | `invalid_address` | Een filter bevat een ongeldig adres. | Maak elk adres een geldig base58-Solana-adres (geen lege strings, spaties of verkeerde lengte). | | `invalid_signature` | De waarde van de transactiesignatuur is niet geldig. | Gebruik een geldige base58-transactiesignatuur. | | `invalid_account_data_filter` | Een datafilter voor accounts is niet geldig. | Corrigeer de filters voor `memcmp`, `datasize` en token-accountdata, en houd het aantal binnen de limiet uit de melding. | | `invalid_data_slice` | De data slices zijn niet geldig. | Sorteer data slices op offset en laat ze elkaar niet overlappen. | | `blocks_include_not_allowed` | De opties van het blocks-abonnement zijn niet beschikbaar op Shared gRPC. | Laat `blocks` weg en gebruik in plaats daarvan een transactie- of `blocks_meta`-abonnement. | | `invalid_token_accounts_mode` | De modus voor token accounts is niet geldig. | Gebruik `ALL` (0) of `BALANCE_CHANGED` (1). | | `invalid_argument` | Geen van de bovenstaande redenen is van toepassing. | Controleer het filter en de parameters van de aanvraag voordat u het opnieuw probeert. | ## V. Wat betekent `ERPC_GRPC_REQUEST_FAILED` wanneer gRPC een andere niet-nulstatus teruggeeft? De aanvraag is mislukt met een geldige gRPC-status die de volgende stap bepaalt. Herstel een aanvraag met `OutOfRange (11)` wanneer een historisch bereik ongeldig is; pas backoff toe bij een beschikbaarheidsstatus zoals `Unavailable (14)`. Classificeer niet elke niet-nulstatus als tijdelijk en herhaal niet elk antwoord ongewijzigd. ## V. Welke regio raden jullie aan? Er is niet één regio die altijd de beste is. Solana is een wereldwijd netwerk, en de leader-rol wisselt volgens het leaderschema tussen validators. Regio's met meer validators en meer stake krijgen vaker leader slots, wat transacties sneller kan laten landen. De keerzijde is dat concurrerend verkeer zich daar ook concentreert, waardoor een minder drukke regio, afhankelijk van uw strategie, soms betere resultaten kan opleveren. Kies als praktisch startpunt een regio met veel validators, zoals Frankfurt of de Amerikaanse oostkust, wanneer een stabiele aanvoer van leader slots het belangrijkst is, of plaats uw infrastructuur dicht bij een specifieke doelvalidator wanneer uitvoering via het kortste pad prioriteit heeft. Gebruik [Validators Solutions](https://validators.solutions/) om inzicht te krijgen in de publieke verdeling van het Solana-netwerk, en gebruik daarna de [ERPC Leader Slot API](https://erpc.global/nl/doc/rpc/leader-slot-api/) en echte metingen om te beslissen of een deployment in één regio, in twee regio's of wereldwijd passend is. [![Solana Mainnet Distribution Report](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/) ## V. Ik heb een latentie van ~400ms of minder nodig. Om een latentie binnen ongeveer 400ms te bereiken, zijn dit de essentiële aandachtspunten: - **Realistisch begrip van pingwaarden**: Pingwaarden geven ideale omstandigheden aan en weerspiegelen niet de werkelijke latentie in streamingcommunicatie, die doorgaans ongeveer 5 keer de pinglatentie bedraagt. Een ping van 100ms tussen continenten resulteert in de praktijk bijvoorbeeld in ongeveer 500ms latentie. Daarom moet infrastructuur in dezelfde regio worden opgezet om ~400ms latentie te bereiken. - Typische pingwaarden ter referentie: - Hetzelfde netwerk: ~0,1ms - Private Network Interconnect (PNI): ~0,2ms - Hetzelfde datacenter: ~0,3ms - Dezelfde stad: ~1ms - Buurland: ~5–10ms - Intercontinentaal: ~100–300ms - **De valkuil van gemiddelde latentie vermijden**: Solana-validators zijn wereldwijd geografisch verspreid en het leaderschema verandert willekeurig bij elke epoch. Vertrouwen op gemiddelde latentie om ~400ms te bereiken is niet realistisch. In plaats daarvan moet u validatorschema's in uw specifieke regio nauwkeurig volgen om slots met de laagste latentie te identificeren. Om consequent minimale latentie te bereiken, is infrastructuur in alle relevante regio's vereist. Binnen dezelfde regio kan gegevensverzameling in tientallen milliseconden plaatsvinden, met transmissie in slechts enkele milliseconden. - **Het leaderschema volgen**: Monitor het leader-validatorschema voor uw regio met behulp van de **ERPC Leader Slot API (`getLeaderSlots`)**. De API retourneert het aankomende leaderschema, de stake weight voor de huidige epoch, geschatte geolocaties van validators en referentie-pingwaarden, zodat u de slots met de laagste latentie kunt bepalen waarop u wilt inzetten, voordat ze aan de beurt zijn. Publieke kaartgegevens en native RPC API's zijn nuttig voor een breed netwerkoverzicht, maar ze zijn niet nauwkeurig genoeg voor uitvoeringstiming. De Leader Slot API vult die leemte met de granulariteit die nodig is voor routerings- en handelsbeslissingen. - [ERPC Leader Slot API-documentatie](https://erpc.global/nl/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/nl) [![Validators Solutions - Solana-netwerkdata](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/) Solana-netwerkdata: [Validators Solutions](https://validators.solutions/) ## V. Hoe kan ik zero-block (zero-slot) trading bereiken? Voor succesvolle zero-block (zero-slot) trading zijn geavanceerdere strategieën nodig: - **Kansenzones identificeren**: Solana-validators zijn wereldwijd verspreid en het is fysiek onmogelijk om optimale latentie voor elke slot te bereiken. Monitor daarom validator-leaderschema's in de regio waar uw infrastructuur zich bevindt en identificeer de gunstigste kansenzones. Het implementeren van infrastructuur in meerdere regio's kan ook voordelig zijn. Frankfurt is bijvoorbeeld een belangrijke regio vanwege de hoge validatordichtheid, wat resulteert in frequentere leaderselectie en meer handelsmogelijkheden. Gebruik de **ERPC Leader Slot API (`getLeaderSlots`)** om het aankomende leaderschema, de stake weight voor de huidige epoch, geschatte geolocatiegegevens van validators en referentie-pingwaarden op te vragen, met veel grotere precisie dan publieke kaartgegevens of native RPC API's. Zo kunt u kansenzones in kaart brengen voordat de slots aan de beurt zijn en trades uitvoeren met een latentie van bijna nul. - [ERPC Leader Slot API-documentatie](https://erpc.global/nl/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/nl) - **Dedicated nodes implementeren**: Als u moeite heeft om te concurreren, overweeg dan dedicated nodes te implementeren. Gedeelde nodes ervaren latentie door verkeer van andere gebruikers en worden daarom niet aanbevolen. Bovendien vermindert het plaatsen van uw dedicated node binnen hetzelfde netwerk als uw applicatie de netwerklatentie aanzienlijk en optimaliseert het de prestaties. ## V. Kan ik een specifiek endpoint gebruiken? Om een omgeving met lage latentie te handhaven, selecteert ons systeem automatisch de dichtstbijzijnde beschikbare node. Als u een specifiek endpoint wilt gebruiken, raden we aan een server te huren die het dichtst bij dat endpoint staat. ## V. Ik krijg een 401-fout. Waarom? Om een omgeving met lage latentie te handhaven, implementeren we IP-beperkingen. Als u geen abonnement heeft of uw IP niet is geregistreerd, ontvangt u een 401-fout. Controleer of uw geregistreerde IP overeenkomt met uw huidige toegangs-IP. ## V. Ik krijg een 429-fout. Waarom? U heeft de verbindingslimiet van uw plan bereikt. Als u deze fout tegenkomt, overweeg dan uw plan te upgraden. Als u meer verbindingen nodig heeft dan ons premium plan biedt, is een dedicated gRPC-node geschikter. ## V. Waarom zijn dedicated endpoints sneller? Gedeelde endpoints worden door meerdere klanten gebruikt die dezelfde resources delen. Naarmate het verkeer toeneemt, treedt er doorgaans latentie op. Serverresources hebben fysieke limieten en de hoeveelheid werk die ze aankunnen is eindig. Wanneer te veel verzoeken tegelijkertijd binnenkomen, moeten ze sequentieel worden verwerkt, wat resulteert in tragere responstijden. Hoewel we diverse maatregelen nemen om prestaties te optimaliseren, zelfs bij gedeelde endpoints, bent u bij dedicated endpoints de enige gebruiker van de resource. Dit betekent dat u volledig onbeïnvloed bent door andere gebruikers, wat consistent stabiele en snelle reacties garandeert. Bovendien bieden dedicated endpoints communicatieopties zonder TLS, zoals HTTP. Door de TLS-handshake (ongeveer 20ms) over te slaan, wordt communicatie nog sneller vergeleken met HTTPS. ## V. Wordt mijn prijs verhoogd nadat ik me abonneer? Zolang uw abonnement actief blijft, blijft de prijs die u bij inschrijving hebt vastgelegd van kracht. Omgevingen die Solana's real-time workload aankunnen zijn wereldwijd schaars, en we zijn van plan de prijzen stapsgewijs te verhogen naarmate hardware- en netwerkvraag groeit. Configuraties met hogere specs en regio's met veel vraag raken het snelst uitverkocht, dus de huidige prijs vastleggen is op lange termijn de meest kostenefficiënte keuze. ## V. Ik wil betalen met crypto Crypto-betalingen zijn beschikbaar via het ERPC Web Dashboard wanneer het land van uw geregistreerde factuuradres een van de EU-lidstaten is. Als alle betaalkaarten in uw account buiten de EU zijn uitgegeven, zijn crypto-betalingen niet beschikbaar. U kunt SOL, USDC of EURC gebruiken om ERPC Credits te kopen. Gebruik die ERPC Credits om ERPC-plannen te activeren of voort te zetten. Open het dashboard, kies Crypto-betalingen, verstuur de betaling vanuit uw wallet, en het dashboard verifieert de transactie en voegt de credits toe aan uw account. Ondersteunde landen: België, Bulgarije, Cyprus, Denemarken, Duitsland, Estland, Finland, Frankrijk, Griekenland, Hongarije, Ierland, Italië, Kroatië, Letland, Litouwen, Luxemburg, Malta, Nederland, Oostenrijk, Polen, Portugal, Roemenië, Slovenië, Slowakije, Spanje, Tsjechië, Zweden. Staat uw land niet in de lijst, betaal dan met creditcard. [ERPC Web Dashboard](https://dashboard.erpc.global/nl) ## V. Hoe kan ik de laagst mogelijke latentie bereiken? We raden sterk aan een dedicated gRPC-node te combineren met onze [Bare-Metal server](https://erpc.global/nl/baremetal/). Beide delen hetzelfde netwerk, wat privécommunicatie op nulafstand mogelijk maakt zonder over het internet te hoeven gaan. Deze setup bereikt extreem lage latentie, doorgaans rond 0,1ms ping. Neem contact met ons op via het ERPC Web Dashboard voor meer details. [ERPC Web Dashboard](https://dashboard.erpc.global/nl) 🔗 [ERPC Web Dashboard](https://dashboard.erpc.global/nl) ## V. Hoe is de latentie? Latentie varieert afhankelijk van de meetmethode en uw specifieke gebruiksomgeving. In plaats van te focussen op exacte numerieke waarden, is het cruciaal om ervoor te zorgen dat de latentie voldoet aan uw werkelijke operationele vereisten. We bieden gebruiksvriendelijke tools in TypeScript en Rust voor het meten van latentie. - [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream) - [SLV (Nederlands)](https://slv.dev/nl) ## V. Is deze RPC (gRPC, Shreds) sneller dan die van anderen? We ontwerpen elk niveau met het oog op snelheid, en we laten dat graag zij aan zij meten met elke andere provider. De resultaten kunnen variëren per regio, per gedeeld of dedicated endpoint, per protocol (WebSockets, gRPC of Shreds) en per programmeertaal van uw client. Als u onze service trager vindt, laat ons dan via het ERPC Web Dashboard weten onder welke omstandigheden en met welke concurrenten u heeft vergeleken. We zullen de oorzaak identificeren en de snelheid verder verbeteren. [ERPC Web Dashboard](https://dashboard.erpc.global/nl) ## V. Welk plan is het snelst? Over het algemeen is ons plan op het hoogste niveau het snelst, dankzij superieure CPU's, meer geheugen en robuuste hardwareconfiguraties. We bieden ook maatwerkoplossingen als u nog krachtigere servers nodig heeft, maar onze standaardplannen zijn ontworpen om optimale prijs-prestatieverhoudingen te leveren. We zijn ervan overtuigd dat we prestaties van wereldklasse bieden op elk prijsniveau. Als u een snellere provider vindt binnen hetzelfde prijsbereik, laat het ons dan weten, zodat we dit kunnen onderzoeken en verbeteringen kunnen aanbrengen. ## V. Ik ervaar hoge latentie. Wat kan ik doen? Latentie hangt sterk af van uw nabijheid tot het endpoint. We raden aan om toegang te krijgen vanaf een server dicht bij het aangeboden endpoint. De snelste verbindingen worden bereikt met onze [Bare-Metal server](https://erpc.global/nl/baremetal/) en [VPS-service](https://erpc.global/nl/vps/). ## V. Wat is het snelst: WebSockets, gRPC of Shreds? Feedback van onze klanten rangschikt de snelheid consistent als volgt: **Shreds > gRPC > WebSockets** Deel uw ervaring als u andere resultaten waarneemt. ## V. De latentie is niet wat ik verwachtte. Prestaties variëren afhankelijk van de gebruikte programmeertaal. Over het algemeen is de volgorde qua snelheid als volgt: **Rust > Go > TypeScript (JavaScript) > Python** Zie voor gedetailleerde vergelijkingen: [Snelheidsvergelijking programmeertalen](https://niklas-heer.github.io/speed-comparison/) Voor maximale prestaties raden we sterk aan Rust te gebruiken.