--- title: "FAQ - Flux Geyser gRPC" description: "Foire aux questions sur le flux Geyser gRPC d'ERPC - Enhanced Solana RPC" canonical: "https://erpc.global/fr/faq/grpc/general/" locale: "fr" --- # FAQ - Flux Geyser gRPC ## Q. Dans quelles régions se trouvent vos nœuds? Nous opérons actuellement des nœuds dans les régions suivantes: - Francfort (FRA) - Amsterdam (AMS) - Londres (LON) - New York (NY) - Tokyo (TY) - Singapour (SGP) - Sydney (SYD) ERPC mesure la latence réelle du réseau à partir des chemins de routage effectifs et sélectionne automatiquement la région offrant la latence la plus faible, plutôt que de se fier à la distance à vol d'oiseau. Cette approche améliore non seulement la latence pour chaque utilisateur, mais aussi l'efficacité globale du réseau, et renforce la résilience mondiale d'ERPC face aux attaques potentielles. Si votre environnement ne sélectionne pas automatiquement la région optimale, veuillez nous contacter via l'ERPC Web Dashboard. ERPC Web Dashboard: https://dashboard.erpc.global/fr ## Q. La latence affiche 9999 ms et une région non optimale est sélectionnée. Que dois-je faire ? Pour la sélection de région de gRPC, ERPC envoie des sondes de latence ICMP à votre adresse IP enregistrée depuis les hôtes proxy répertoriés ci-dessous. Autorisez les requêtes d’écho ICMP entrantes provenant de chaque adresse IP source répertoriée. Si elles sont bloquées par un pare-feu (ufw, pare-feu cloud, groupe de sécurité, etc.), la mesure peut atteindre `9999ms` et une région non optimale peut être sélectionnée. Plusieurs adresses IP dans une même région correspondent à des hôtes de sonde distincts ; elles sont toutes requises. [ERPC_PING_SOURCES:grpc]: # | Région | Adresses IP sources ICMP | | --- | --- | | 🇳🇱 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. J'ai autorisé mon IP, mais je n'arrive toujours pas à me connecter. Que dois-je vérifier ? Utilisez l’endpoint HTTPS chiffré sélectionné dans le dashboard. HTTPS utilise le port 443 ; HTTP sur le port 80 reste l’option non chiffrée à faible latence. Les deux transports utilisent la même allowlist d’IP enregistrées. Utilisez l’endpoint sélectionné dans le dashboard : HTTPS sur 443 ou HTTP sur 80. - Endpoint HTTPS : utilisez l’endpoint sélectionné dans le dashboard sur le port 443. - Endpoint HTTP : utilisez l’endpoint sélectionné dans le dashboard sur le port 80. - Utilisez l’URL affichée dans le dashboard avec `https://` ou `http://`. L'authentification se fait par votre adresse IP enregistrée. N'ajoutez pas d'en-têtes `x-token`, `token` ou `Authorization` sauf indication explicite sur une page produit spécifique. ## Q. Je n'ai utilisé que WebSocket jusqu'ici. Puis-je utiliser gRPC ? Avez-vous des exemples ? Oui. Vous pouvez rapidement tester et commencer à développer avec gRPC en utilisant SLV. Pour un endpoint partagé que vous pouvez tester sans jeton, exécutez: ```bash slv check grpc --endpoint --token none ``` Consultez notre [guide de démarrage rapide de gRPC](https://slv.dev/fr/doc/geyser-grpc/quickstart/) pour plus de détails. ## Q. Puis-je enregistrer deux adresses IP? Vous pouvez utiliser un endpoint par abonnement. Si vous souhaitez utiliser deux adresses IP, vous devez souscrire deux abonnements distincts. ## Q. Y a-t-il des limites de filtre? Geyser gRPC Shared applique des protections d'usage raisonnable afin qu'un stream ne consomme pas les ressources nécessaires aux autres clients ERPC. Avec la règle Shared actuelle, toute map `blocks` non vide est rejetée, y compris une requête de blocs restreinte. Chaque filtre de compte doit comporter `account`, `owner` ou un filtre cuckoo pris en charge ; `memcmp` ou `dataSize` seuls ne suffisent pas. Supprimez une forme rejetée et abonnez-vous seulement aux données dont votre application a besoin. Une souscription aux transactions ou les métadonnées de blocs peuvent convenir sans transporter un bloc complet. Geyser gRPC Dedicated convient lorsqu'une charge légitime dépasse l'enveloppe Shared de forme ou de ressources ; il ne rend pas valides des paramètres invalides et ne répare pas un client lent. ## Q. Comment collecter une erreur gRPC avant de me reconnecter? Conservez la première erreur avant qu'une boucle de reconnexion ne la remplace. Notez l'état et le message gRPC des métadonnées initiales et des trailers, ainsi que `x-erpc-error-code`, `x-erpc-error-reason` et `x-erpc-doc-url`. Lorsqu'ERPC indique une pause, notez aussi `x-erpc-retry-after-seconds` et `x-erpc-retry-at` (secondes Unix). Une erreur peut s'afficher sous la forme `ERPC [STREAM_GUARD_SLOW_READER]: ...`. Collez l'erreur affichée ou son code dans la recherche FAQ. L'explication canonique est disponible dans la [FAQ gRPC ERPC](https://erpc.global/fr/faq/grpc/general/). Ne supposez pas qu'un trailer sera livré lorsqu'une connexion se termine tôt. Vous pouvez aussi rechercher un symptôme : récepteur lent, déconnecté, bande passante, retard de livraison, arriéré, pause, réessai, argument invalide, ressource épuisée, permission refusée, enregistrement IP, trop de streams, blocs complets ou tous les comptes. ## Q. Quelles erreurs gRPC mettent ma connexion en pause, et quand mon client doit-il arrêter de se reconnecter? Une pause est une période d'une durée déterminée qu'ERPC applique après certaines erreurs. Le client ne doit pas se reconnecter tant qu'elle est en cours. **Ce qui est compté.** Ces erreurs sont comptées et partagent une même suite de paliers : - Chaque requête Subscribe qu'ERPC rejette avec `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` ou `STREAM_GUARD_SHAPE_ACCOUNTS_ALL`, y compris la première. La première erreur comptée est l'avertissement, qui ne déclenche aucune pause. - `STREAM_GUARD_SLOW_READER`. Toutefois, si le retard de livraison apparaît du côté d'ERPC, ERPC ferme le stream sans que cela soit compté, et l'erreur ne contient aucune échéance de réessai. Ne sont pas comptés : la reconnexion elle-même, les quatre codes `STREAM_ADMISSION_*` (`STREAM_ADMISSION_LIMIT_REACHED`, `STREAM_ADMISSION_IP_NOT_ADMITTED`, `STREAM_ADMISSION_SOURCE_UNAVAILABLE` et `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE`) et toute erreur comptée qui survient pendant qu'une pause est en cours. Une erreur comptée pendant une pause ne prolonge pas la pause et ne passe pas au palier suivant. **Les paliers.** Chaque erreur comptée avance d'un palier dans cet ordre, en commençant par l'avertissement : - Avertissement : aucune pause. - Pause de 60 secondes. - Pause de 300 secondes. - Pause de 1800 secondes. - Pause de 86400 secondes (24 heures). C'est le dernier palier : une fois celui-ci atteint, chaque erreur comptée déclenche une nouvelle pause de 86400 secondes. Au palier de l'avertissement, l'erreur comptée suivante ne passe à la pause de 60 secondes que si elle survient dans un délai de 1 heure à compter de l'avertissement. Une erreur comptée qui survient plus de 1 heure après l'avertissement est un autre avertissement sans pause, et la fenêtre de 1 heure court alors à partir de ce nouvel avertissement. Une erreur comptée qui survient moins de 60 secondes après la dernière erreur comptée compte comme faisant partie de cette erreur et n'avance d'aucun palier. **Quand les paliers reviennent à l'avertissement.** Une fois que les paliers ont déclenché une pause, ils ne reviennent à l'avertissement qu'après 24 heures sans erreur comptée et sans pause, mesurées à partir de la fin de la dernière pause ; après cela, l'erreur comptée suivante est un avertissement sans pause. D'ici là, l'erreur comptée suivante déclenche immédiatement le palier suivant, sans avertissement. **La pause d'egress.** `STREAM_GUARD_EGRESS_BUDGET` déclenche sa propre pause fixe de 600 secondes. Ce code ne fait pas progresser les paliers. **Où se trouve l'heure de fin.** - L'erreur qui déclenche une pause contient `Retry after N seconds.` ainsi que les en-têtes `x-erpc-retry-after-seconds` et `x-erpc-retry-at` (secondes Unix). L'avertissement ne contient aucune échéance de réessai. - Lorsqu'une requête rejetée comptée est celle qui déclenche une pause, elle est renvoyée sous la forme `STREAM_GUARD_SHAPE_REJECT_PENALTY` avec `ResourceExhausted (8)` au lieu de son propre code. - Pendant une pause due à un lecteur lent ou à l'egress, une reconnexion reçoit `STREAM_GUARD_PENALTY_ACTIVE` avec le temps restant. - Pendant une pause déclenchée par une requête rejetée, une nouvelle connexion est fermée immédiatement, sans état gRPC ni code ERPC. Une requête sur une connexion encore ouverte peut de nouveau recevoir en réponse `STREAM_GUARD_SHAPE_REJECT_PENALTY` avec le temps restant, avant que cette connexion ne soit fermée. Le client peut ne plus jamais voir l'heure de fin ; il doit donc enregistrer `x-erpc-retry-at` à partir de la première erreur qui le contient. | Code | État gRPC | Déclenche une pause ou fait progresser les paliers ? | Ce que le client doit faire | | --- | --- | --- | --- | | `ERPC_GRPC_INVALID_ARGUMENT` | `InvalidArgument (3)` | Oui, lorsqu'il rejette une requête Subscribe. C'est alors une erreur comptée selon les paliers ci-dessus. | Arrêtez la boucle et ne renvoyez pas la même requête. Son entrée dédiée ci-dessous indique ce qu'il faut vérifier. | | `STREAM_GUARD_SHAPE_BLOCKS` | `PermissionDenied (7)` | Oui. C'est une erreur comptée selon les paliers ci-dessus. | Arrêtez la boucle et ne renvoyez pas la même requête. Son entrée dédiée ci-dessous indique ce qu'il faut vérifier. | | `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` | `PermissionDenied (7)` | Oui. C'est une erreur comptée selon les paliers ci-dessus. | Arrêtez la boucle et ne renvoyez pas la même requête. Son entrée dédiée ci-dessous indique ce qu'il faut vérifier. | | `STREAM_GUARD_SLOW_READER` | `ResourceExhausted (8)` | Oui. C'est une erreur comptée selon les paliers ci-dessus. Toutefois, si le retard de livraison apparaît du côté d'ERPC, ERPC ferme le stream sans que cela soit compté, et l'erreur ne contient aucune échéance de réessai. | Arrêtez la boucle. Son entrée dédiée ci-dessous indique ce qu'il faut vérifier. Si ce code a déclenché une pause, ne vous reconnectez pas avant l'heure indiquée dans `x-erpc-retry-at`. | | `STREAM_GUARD_EGRESS_BUDGET` | `ResourceExhausted (8)` | Oui. Il déclenche une pause fixe de 600 secondes en dehors des paliers ci-dessus. | Ne vous reconnectez pas avant l'heure indiquée dans `x-erpc-retry-at`. Son entrée dédiée ci-dessous indique ce qu'il faut vérifier. | | `STREAM_GUARD_SHAPE_REJECT_PENALTY` | `ResourceExhausted (8)` | Oui. C'est la requête rejetée comptée qui a déclenché une pause. Ce code peut de nouveau être reçu avec le temps restant sur une connexion encore ouverte. | Ne vous reconnectez pas avant l'heure indiquée dans `x-erpc-retry-at`. Corrigez la requête rejetée et ne la renvoyez pas inchangée. | | `STREAM_GUARD_PENALTY_ACTIVE` | `ResourceExhausted (8)` | Non. Il signale une pause déjà en cours, due à un lecteur lent ou à l'egress. | Ne vous reconnectez pas avant l'heure indiquée dans `x-erpc-retry-at`. | | `STREAM_ADMISSION_LIMIT_REACHED` | `ResourceExhausted (8)` | Non. Il ne comporte aucune pause temporisée. | Fermez les streams inutilisés, puis réessayez. | | `STREAM_ADMISSION_IP_NOT_ADMITTED` | `PermissionDenied (7)` | Non. Il ne comporte aucune pause temporisée. | Son entrée dédiée ci-dessous indique ce qu'il faut vérifier. | | `STREAM_ADMISSION_SOURCE_UNAVAILABLE` | `Unavailable (14)` | Non. Il ne comporte aucune pause temporisée. | Appliquez votre backoff habituel et réessayez après un délai. | | `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` | `Unavailable (14)` | Non. Il ne comporte aucune pause temporisée. | Appliquez votre backoff habituel et réessayez après un délai. | **Ce que le client doit faire.** En cas d'erreur comptée, arrêtez la boucle, ne renvoyez pas la même requête et corrigez-la. Pendant une pause, ne vous reconnectez pas avant l'heure indiquée dans `x-erpc-retry-at`. Les requêtes Subscribe rejetées sont comptées selon les règles ci-dessus, la reconnexion ne l'est pas. ## Q. Que signifie `STREAM_GUARD_SLOW_READER` avec `ResourceExhausted (8)` lorsqu'un récepteur lent est déconnecté? ERPC a observé peu de progression d'écriture ou un retard de livraison sur ce stream. Le seul retard de livraison ne permet pas d'identifier la cause. Vérifiez les pertes réseau, la bande passante effective, la capacité de l'hôte et la capacité du consommateur applicatif à suivre. Réduisez les données souscrites et sortez le traitement de la boucle de réception vers une file bornée. Une file bornée limite la mémoire, mais ne peut pas résoudre un consommateur durablement lent. Si ERPC fournit une échéance de réessai, attendez-la avant de vous reconnecter. La question « Pourquoi mon stream gRPC reste-t-il à une vitesse constante et prend-il du retard? » ci-dessous explique la fenêtre de réception et comment l'agrandir dans la bibliothèque de votre client. ## Q. Pourquoi mon stream gRPC reste-t-il à une vitesse constante et prend-il du retard? Une petite fenêtre de réception dans votre client, ou dans un élément situé entre celui-ci et ERPC, peut provoquer des coupures `STREAM_GUARD_SLOW_READER` et les pauses qui les suivent. Cette réponse explique ce qu'est une fenêtre de réception, comment savoir si elle limite votre stream et comment l'agrandir selon la bibliothèque. La question « Quelles erreurs gRPC mettent ma connexion en pause, et quand mon client doit-il arrêter de se reconnecter? » ci-dessus donne les paliers et leurs durées. **Ce qu'est une fenêtre de réception.** En HTTP/2, le récepteur indique à l'émetteur la quantité de données qui peut être envoyée avant que le récepteur ne confirme ; cette quantité est la fenêtre de réception (la fenêtre de contrôle de flux HTTP/2). Un aller-retour transporte au plus une fenêtre, donc la vitesse plafonne à peu près à la fenêtre divisée par le temps aller-retour (le trajet jusqu'à l'endpoint et retour). **Les autres limites.** Il y a deux fenêtres, une par stream et une par connexion (tous les streams d'une connexion la partagent), et la plus petite fixe la limite. Dans la spécification HTTP/2, les deux fenêtres commencent à 65 535 octets. Le tampon de réception TCP (la mémoire des données entrantes) limite la vitesse de la même façon. Un proxy, un load balancer, une passerelle, un VPN ou un sidecar placé entre votre client et ERPC a ses propres fenêtres et tampons. Une petite fenêtre ou un petit tampon à cet endroit plafonne le stream, même lorsque les fenêtres de votre propre client sont grandes. **À quoi cela ressemble.** Un stream se stabilise à presque la même vitesse quelle que soit l'activité de la chaîne, et son retard de livraison augmente régulièrement. ERPC a mesuré depuis un emplacement situé à un temps aller-retour d'environ 6 ms de l'endpoint Shared de Frankfurt, en ne changeant que la fenêtre d'un essai à l'autre : - Fenêtre de stream de 16 KiB : stable à environ 2,7 MB/s (16 KiB divisés par 6 ms) ; le retard de livraison a augmenté d'environ 0,6 seconde par seconde, pour atteindre 26 secondes en 45 secondes. - Les deux à 16 MiB : le retard de livraison maximal était de 14 ms. Si le retard de livraison apparaît du côté d'ERPC, ERPC ferme le stream sans que cela soit compté, et l'erreur ne contient aucune échéance de réessai. **Comment vérifier.** 1. Comparez la vitesse et le retard de livraison du stream avec le schéma ci-dessus. 2. Mesurez le temps aller-retour. Multipliez la vitesse du stream par le temps aller-retour pour estimer la fenêtre (2,7 MB/s fois 6 ms donne environ 16 KB). 3. Vérifiez si l'une des deux fenêtres de votre client a une petite valeur, ou si la croissance automatique (la bibliothèque qui agrandit la fenêtre) est désactivée. 4. Vérifiez le tampon de réception TCP. Sous Linux, exécutez `sysctl net.ipv4.tcp_rmem net.core.rmem_max` et regardez si votre application définit `SO_RCVBUF`, ce qui désactive le dimensionnement automatique. 5. Vérifiez les fenêtres et les tampons de tout ce qui se trouve entre votre client et ERPC. 6. Si la vitesse n'a pas de plafond et que seul le retard augmente, c'est le traitement après réception qui est lent. La question « Que signifie `STREAM_GUARD_SLOW_READER` avec `ResourceExhausted (8)` lorsqu'un récepteur lent est déconnecté? » ci-dessus explique comment limiter la boucle de réception à la lecture et déplacer le travail lourd vers une file bornée. **Réglages par bibliothèque.** Les exemples fixent les deux fenêtres à 16 MiB, comme dans la mesure d'ERPC. Pour une bibliothèque absente de la liste, cherchez les réglages de fenêtre initiale HTTP/2. **Rust, `yellowstone-grpc-client`.** Sans réglage de fenêtre, `GeyserGrpcClient::build_from_shared` utilise 2 MiB par stream et 5 MiB par connexion. Avec un aller-retour de 6 ms, ces valeurs par défaut permettent plus de 300 MB/s ; elles ne plafonnent donc pas le stream. Pour fixer vous-même les fenêtres, utilisez les deux méthodes du builder et laissez `http2_adaptive_window` désactivé. S'il est activé, la fenêtre commence à 65 535 octets et grandit d'elle-même jusqu'à 16 MiB, sans tenir compte de vos valeurs. ```rust // Les deux fenêtres fixées à 16 MiB ; laisser http2_adaptive_window désactivé. 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 ou version ultérieure.** Valeurs par défaut : 4 MiB par stream, 8 MiB par connexion, croissance automatique activée. La fenêtre commence à 64 KiB et grandit jusqu'à 16 MiB, donc les valeurs par défaut plafonnent rarement le stream. Pour fixer les tailles, passez le troisième argument avec `grpcHttp2AdaptiveWindow: false`. ```typescript // Fenêtre adaptative désactivée, donc ces tailles fixes s'appliquent. const client = new Client(endpoint, undefined, { grpcInitialStreamWindowSize: 16 * 1024 * 1024, grpcInitialConnectionWindowSize: 16 * 1024 * 1024, grpcHttp2AdaptiveWindow: false, }) ``` **TypeScript, `@triton-one/yellowstone-grpc` 5.0.0 ou version antérieure.** Ces versions utilisent `@grpc/grpc-js`, dont la fenêtre par défaut est de 65 535 octets : environ 11 MB/s à 6 ms, environ 0,66 MB/s à 100 ms. À partir de la version 1.14, `@grpc/grpc-js` applique `'grpc-node.flow_control_window'` aux deux fenêtres ; la version 1.13 ne l'applique qu'à la fenêtre de stream, si bien que la fenêtre de connexion reste à 65 535 octets (environ 11 MB/s à 6 ms). Avec une version de `@grpc/grpc-js` antérieure à la 1.14, le plus rapide est de passer à `@triton-one/yellowstone-grpc` 5.0.1 ou version ultérieure. ```typescript // Nécessite @grpc/grpc-js 1.14 ou version ultérieure pour agrandir les deux fenêtres. const client = new Client(endpoint, undefined, { 'grpc-node.flow_control_window': 16 * 1024 * 1024, }) ``` **Go, `google.golang.org/grpc`.** Par défaut, la bibliothèque agrandit elle-même les fenêtres, jusqu'à 16 MiB. `grpc.WithInitialWindowSize` et `grpc.WithInitialConnWindowSize` les fixent et désactivent la croissance automatique ; les valeurs inférieures à 64 KiB sont ignorées. Définissez les deux : si vous n'en définissez qu'une, l'autre fenêtre reste à 64 KiB. ```go // Définir les deux ; cela désactive aussi la croissance automatique de la fenêtre. conn, err := grpc.NewClient(target, grpc.WithTransportCredentials(creds), grpc.WithInitialWindowSize(16<<20), grpc.WithInitialConnWindowSize(16<<20), ) ``` **Python, `grpcio`.** `grpc.http2.bdp_probe` est activé par défaut, donc les fenêtres grandissent d'elles-mêmes ; si votre code passe `("grpc.http2.bdp_probe", 0)`, supprimez-le. `grpc.http2.lookahead_bytes` définit la lecture anticipée par stream (64 KB par défaut) ; des valeurs plus grandes peuvent aider sur un long aller-retour. ```python # Si vos options contiennent ("grpc.http2.bdp_probe", 0), supprimez cette entrée. channel = grpc.secure_channel(target, creds, options=[ ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024), ]) ``` **Recevoir plus près.** Un aller-retour plus court permet à la même fenêtre de livrer davantage, et le [service VPS](https://erpc.global/fr/vps/) et les [serveurs bare metal](https://erpc.global/fr/baremetal/) d'ERPC placent le client près de l'endpoint. **Répartir avec prudence.** Standard autorise 10 streams et Premium 50, par IP source enregistrée. Chaque stream a sa propre fenêtre de stream, mais les streams d'une même connexion partagent une seule fenêtre de connexion ; une petite fenêtre de connexion limite donc toujours la vitesse. Pour remplacer un stream, fermez d'abord l'ancien : les streams ouverts entrent dans la limite, et la dépasser renvoie `STREAM_ADMISSION_LIMIT_REACHED` (sa propre question se trouve ci-dessous). Répartir n'accélère pas un traitement lent. ## Q. Que signifie `STREAM_GUARD_EGRESS_BUDGET` avec `ResourceExhausted (8)`? Le trafic agrégé de l'IP a dépassé l'allocation Shared ; des streams associés peuvent donc se fermer ensemble. Réduisez le volume de données et les streams parallèles inutiles, puis attendez l'échéance renvoyée. Cette pause d'egress dure 600 secondes et ne fait pas progresser l'échelle de pénalités, mais une pause existante plus longue peut rester en vigueur. ## Q. Que signifie `STREAM_GUARD_PENALTY_ACTIVE` avec `ResourceExhausted (8)`? Une précédente pause due à un lecteur lent ou à l'egress est toujours en cours, et cette réponse contient le temps restant. Conservez la première erreur ERPC, corrigez sa cause et ne vous reconnectez pas avant `x-erpc-retry-at` ; ne vous reconnectez pas tôt pour tester. Les tentatives de reconnexion ne sont pas comptées. La question « Quelles erreurs gRPC mettent ma connexion en pause, et quand mon client doit-il arrêter de se reconnecter? » ci-dessus donne les paliers et leurs durées. ## Q. Que signifie `STREAM_GUARD_SHAPE_BLOCKS` avec `PermissionDenied (7)`? La règle Shared actuelle rejette toute map `blocks` non vide, même avec une requête restreinte. Supprimez la map `blocks`. Utilisez les transactions et/ou les métadonnées de blocs lorsqu'elles répondent au besoin ; aucune n'équivaut à un bloc complet. Les blocs complets exigent Geyser gRPC Dedicated ; cela ne signifie pas qu'une offre de blocs sélectifs Shared existe. ## Q. Que signifie `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` avec `PermissionDenied (7)`? Une entrée de filtre de compte doit sélectionner les données avec `account`, `owner` ou un filtre cuckoo pris en charge. `memcmp` et `dataSize` ne suffisent pas seuls. Limitez la requête de comptes à l'une de ces formes prises en charge ou utilisez Geyser gRPC Dedicated lorsqu'un stream de comptes complet est nécessaire. ## Q. Que signifie `STREAM_GUARD_SHAPE_REJECT_PENALTY` avec `ResourceExhausted (8)`? Ce code est renvoyé à la place de `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` ou `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` lorsque cette requête rejetée comptée est celle qui déclenche une pause ; la question « Quelles erreurs gRPC mettent ma connexion en pause, et quand mon client doit-il arrêter de se reconnecter? » ci-dessus indique quand cela se produit. Il contient `Retry after N seconds.`, `x-erpc-retry-after-seconds` et `x-erpc-retry-at`. Pendant cette pause, les nouvelles connexions sont fermées immédiatement, sans état gRPC ni code ERPC ; le client peut donc ne plus jamais voir l'heure de fin. Enregistrez `x-erpc-retry-at` à partir de la première erreur qui le contient. Les requêtes Subscribe rejetées sont comptées selon les règles ci-dessus, la reconnexion ne l'est pas. Corrigez la requête et ne la renvoyez pas inchangée. Une fermeture précoce peut ressembler à une erreur de transport ; conservez donc la première erreur ERPC avant que la boucle de reconnexion ne la masque. ## Q. Que signifie `STREAM_ADMISSION_LIMIT_REACHED` avec `ResourceExhausted (8)`? La capacité d'admission est actuellement pleine. Fermez les streams inutilisés ou dupliqués, vérifiez l'allocation de la connexion et réessayez lorsque de la capacité est disponible. Cette réponse ne signifie pas à elle seule qu'une pénalité temporisée est active. ## Q. Que signifie `STREAM_ADMISSION_IP_NOT_ADMITTED` avec `PermissionDenied (7)`? ERPC n'a pas pu admettre la connexion, y compris après l'expiration d'une période de grâce d'enregistrement IP. Comparez l'IP de sortie réelle avec l'IP enregistrée et confirmez l'état d'accès actuel. Laissez une modification d'enregistrement se propager sans supposer de délai fixe, puis contactez le support si la situation persiste. ## Q. Que signifie `STREAM_ADMISSION_SOURCE_UNAVAILABLE` avec `Unavailable (14)`? ERPC n'a pas pu déterminer la source de cette connexion à ce moment. Appliquez un backoff et réessayez plus tard. Si cela persiste, contactez le support avec la première erreur et ses métadonnées ; cette réponse n'établit pas une faute du réseau ou du serveur du client. ## Q. Que signifie `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` avec `Unavailable (14)`? ERPC n'a pas pu vérifier l'accès à ce moment. Appliquez un backoff et réessayez plus tard, puis contactez le support si le problème continue. Réenregistrer à répétition, élargir les filtres ou acheter Geyser gRPC Dedicated ne corrige pas cette réponse de disponibilité. ## Q. Que signifie `ERPC_GRPC_INVALID_ARGUMENT` avec `InvalidArgument (3)`? La requête contient des paramètres, options, types de champ, clés ou combinaisons de filtres invalides. Réparez-la avant de réessayer, et ne renvoyez pas la même requête. Chaque requête Subscribe rejetée avec ce code est une erreur comptée selon les règles de pause de la question « Quelles erreurs gRPC mettent ma connexion en pause, et quand mon client doit-il arrêter de se reconnecter? » ci-dessus, règles partagées avec `STREAM_GUARD_SHAPE_BLOCKS`, `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` et `STREAM_GUARD_SLOW_READER`. Lorsqu'une telle requête déclenche une pause, elle est renvoyée sous la forme `STREAM_GUARD_SHAPE_REJECT_PENALTY` avec `ResourceExhausted (8)`. Geyser gRPC Dedicated ne rend pas valides des paramètres invalides. Le message d'erreur termine le code par `(reason: )`, et le même token est renvoyé dans l'en-tête de réponse `x-erpc-error-reason`. Repérez le token ci-dessous pour savoir quoi modifier. Lorsqu'une limite s'applique, le message d'erreur l'indique. | Reason | Signification | Ce qu'il faut modifier | | --- | --- | --- | | `too_many_filters` | La requête contient plus de filtres nommés ou de data slices qu'une requête n'en admet. | Utilisez moins de filtres nommés (ou de data slices) de ce type par requête. | | `empty_filter` | Un filtre n'a aucune adresse, et un filtre vide signifie tout. | Donnez à chaque filtre au moins une adresse (accounts : un compte ou un owner ; transactions : une liste de comptes). Shared gRPC ne sert pas de filtre vide. | | `too_many_addresses` | Un champ de filtre énumère trop d'adresses. | Utilisez moins d'adresses dans un champ de filtre ; répartissez-les entre plusieurs filtres ou réduisez la liste. | | `address_not_allowed` | Un filtre nomme une adresse que Shared gRPC n'autorise pas. | Retirez du filtre cette adresse à fort volume. | | `filter_name_too_long` | Le nom d'un filtre est trop long. | Utilisez des noms de filtre plus courts (les clés de la map). | | `invalid_commitment` | Le niveau de commitment n'est pas valide. | Utilisez `processed`, `confirmed` ou `finalized`. | | `invalid_address` | Un filtre contient une adresse non valide. | Chaque adresse doit être une adresse Solana base58 valide (pas de chaîne vide, d'espace ni de longueur incorrecte). | | `invalid_signature` | La valeur de la signature de transaction n'est pas valide. | Utilisez une signature de transaction base58 valide. | | `invalid_account_data_filter` | Un filtre de données d'accounts n'est pas valide. | Corrigez les filtres `memcmp`, `datasize` et de données de token accounts, et gardez leur nombre dans la limite indiquée par le message. | | `invalid_data_slice` | Les data slices ne sont pas valides. | Triez les data slices par offset et évitez qu'ils se chevauchent. | | `blocks_include_not_allowed` | Les options de l'abonnement blocks ne sont pas disponibles sur Shared gRPC. | Omettez `blocks` et utilisez plutôt un abonnement aux transactions ou à `blocks_meta`. | | `invalid_token_accounts_mode` | Le mode des token accounts n'est pas valide. | Utilisez `ALL` (0) ou `BALANCE_CHANGED` (1). | | `invalid_argument` | Aucun des motifs ci-dessus ne s'applique. | Vérifiez le filtre et les paramètres de la requête avant de réessayer. | ## Q. Que signifie `ERPC_GRPC_REQUEST_FAILED` lorsque gRPC renvoie un autre état non nul? La requête a échoué avec un état gRPC valide qui détermine la suite. Réparez une requête avec `OutOfRange (11)` lorsqu'une plage historique est invalide ; appliquez un backoff face à un état de disponibilité tel que `Unavailable (14)`. Ne classez pas tout état non nul comme transitoire et ne réessayez pas chaque réponse sans changement. ## Q. Quelle région recommandez-vous? Il n'existe pas de région qui soit la meilleure en permanence. Solana est un réseau mondial, et le rôle de leader passe d'un validateur à l'autre selon le planning des leaders. Les régions avec davantage de validateurs et un stake plus élevé obtiennent plus souvent des slots leaders, ce qui peut aider les transactions à être confirmées plus vite. En contrepartie, le trafic concurrent s'y concentre aussi; une région moins saturée peut donc parfois donner de meilleurs résultats selon votre stratégie. Comme point de départ, choisissez une région dense en validateurs, comme Francfort ou la côte Est des États-Unis, lorsque la disponibilité régulière de slots leaders compte le plus. Placez-vous plutôt près d'un validateur cible précis lorsque l'exécution par le chemin le plus court est prioritaire. Utilisez [Validators Solutions](https://validators.solutions/) pour comprendre la distribution publique du réseau Solana, puis l'[ERPC Leader Slot API](https://erpc.global/fr/doc/rpc/leader-slot-api/) et des mesures réelles pour décider si un déploiement mono-région, bi-région ou global est approprié. [![Rapport sur la distribution du mainnet Solana](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/) ## Q. J'ai besoin d'une latence d'environ 400 ms ou moins. Pour atteindre une latence d'environ 400 ms ou moins, tenez compte de ces points essentiels: - **Compréhension réaliste des valeurs du ping**: Les valeurs de ping indiquent des conditions idéales et ne reflètent pas la latence réelle des communications en streaming, qui est généralement de l'ordre de cinq fois la latence du ping. Par exemple, un ping de 100 ms entre continents se traduit en pratique par environ 500 ms de latence. Ainsi, des infrastructures doivent être mises en place dans la même région pour atteindre ~400 ms de latence. - Références typiques de ping: - Même réseau: ~0,1 ms - Interconnexion réseau privée (PNI): ~0,2 ms - Même centre de données: ~0,3 ms - Même ville: ~1 ms - Pays voisin: ~5–10 ms - Intercontinental: ~100–300 ms - **Éviter le piège de la latence moyenne**: Les validateurs de Solana sont dispersés géographiquement à l'échelle mondiale, et le planning des leaders change de façon aléatoire à chaque époque. Il n'est pas réaliste de s'appuyer sur la latence moyenne pour atteindre ~400 ms. Au lieu de cela, vous devriez suivre précisément les plannings des validateurs dans votre région spécifique pour identifier les slots avec la latence la plus basse. Pour obtenir une latence minimale de façon constante, il faut une infrastructure dans toutes les régions concernées. Dans la même région, l'acquisition de données peut se faire en dizaines de millisecondes, la transmission étant possible en quelques millisecondes seulement. - **Suivi du planning des leaders**: Surveillez le planning des validateurs leaders de votre région avec l'**ERPC Leader Slot API (`getLeaderSlots`)**. Elle renvoie le planning des prochains leaders, le poids de stake de l'époque en cours, la géolocalisation estimée des validateurs et des valeurs de ping de référence, pour que vous puissiez identifier les slots offrant la latence la plus faible et les cibler avant qu'ils n'arrivent. Les données publiques de type carte et les API RPC natives sont utiles pour obtenir une vue d'ensemble du réseau, mais elles ne sont pas assez précises pour le timing d'exécution. La Leader Slot API comble cette lacune avec la granularité nécessaire pour le routage et les décisions de trading. - [Documentation de l'ERPC Leader Slot API](https://erpc.global/fr/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/fr) [![Validators Solutions - Données du réseau Solana](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/) Données du réseau Solana: [Validators Solutions](https://validators.solutions/) ## Q. Comment puis-je réaliser le trading zero-block (zero-slot)? Réussir le trading zero-block (zero-slot) nécessite des stratégies plus sophistiquées, comme suit: - **Identification des zones d'opportunité**: Les validateurs Solana sont répartis dans le monde entier, et il est physiquement impossible d'obtenir une latence optimale sur chaque slot. Par conséquent, surveillez les plannings des validateurs leaders dans la région où se trouve votre infrastructure et identifiez les zones d'opportunité les plus favorables. Le déploiement d'infrastructures dans plusieurs régions peut également être avantageux. Par exemple, Francfort est une région clé en raison de sa forte densité de validateurs, ce qui entraîne une sélection plus fréquente des leaders et de meilleures opportunités de trading. Utilisez l'**ERPC Leader Slot API (`getLeaderSlots`)** pour consulter le planning des prochains leaders, le poids de stake de l'époque en cours, des données de géolocalisation estimée des validateurs et des valeurs de ping de référence, avec une précision bien supérieure à celle des sources de données publiques de type carte ou des API RPC natives. Vous pouvez ainsi cartographier les zones d'opportunité avant l'arrivée des slots et exécuter des trades à latence quasi nulle. - [Documentation de l'ERPC Leader Slot API](https://erpc.global/fr/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/fr) - **Mise en œuvre des nœuds dédiés**: Si vous avez du mal à rivaliser, envisagez de déployer des nœuds dédiés. Les nœuds partagés subissent la latence générée par le trafic d'autres utilisateurs et ne sont donc pas recommandés. De plus, placer votre nœud dédié dans le même réseau que votre application réduit considérablement la latence du réseau et optimise les performances. ## Q. Puis-je utiliser un endpoint spécifique? Pour maintenir un environnement à faible latence, notre système sélectionne automatiquement le nœud disponible le plus proche. Si vous souhaitez utiliser un endpoint spécifique, nous vous recommandons de louer un serveur situé au plus près de cet endpoint. ## Q. Je reçois une erreur 401. Pourquoi? Pour maintenir un environnement à faible latence, nous appliquons des restrictions d'IP. Si vous n'avez pas d'abonnement ou si votre IP n'est pas enregistrée, vous recevrez une erreur 401. Veuillez vérifier que votre IP enregistrée correspond à votre IP d'accès actuelle. ## Q. Je reçois une erreur 429. Pourquoi? Vous avez atteint la limite de connexion de votre plan. Si vous rencontrez cette erreur, envisagez de passer à une offre supérieure. Si vous avez besoin de plus de connexions que notre forfait premium, un nœud dédié gRPC serait plus approprié. ## Q. Pourquoi les endpoints dédiés sont-ils plus rapides? Les endpoints partagés sont utilisés par plusieurs clients qui se partagent les mêmes ressources. Lorsque le trafic augmente, de la latence a tendance à apparaître. Les ressources serveur ont des limites physiques, et la quantité de travail qu'elles peuvent traiter est finie. Lorsque trop de requêtes arrivent en même temps, elles doivent être traitées l'une après l'autre, ce qui ralentit les temps de réponse. Même si nous prenons diverses mesures pour optimiser les performances, y compris sur les endpoints partagés, avec un endpoint dédié vous êtes l'unique utilisateur de la ressource. Vous n'êtes donc aucunement affecté par les autres utilisateurs, ce qui garantit des réponses toujours stables et rapides. Les endpoints dédiés offrent aussi des options de communication sans TLS, comme HTTP. En évitant le handshake TLS (environ 20 ms), la communication devient encore plus rapide qu'en HTTPS. ## Q. Mon prix augmentera-t-il après mon abonnement? Tant que votre abonnement reste actif, le prix obtenu à l'inscription reste appliqué. Les environnements capables d'encaisser les charges temps réel de Solana sont rares à l'échelle mondiale, et nous prévoyons de relever progressivement les prix à mesure que la demande en matériel et en réseau augmente. Les configurations haut de gamme et les régions très demandées partent le plus vite; sécuriser le prix actuel est donc le choix le plus rentable à long terme. ## Q. Je veux payer en crypto Les paiements en crypto sont disponibles depuis l'ERPC Web Dashboard lorsque le pays de votre adresse de facturation enregistrée fait partie des pays membres de l'UE. Si toutes les cartes de paiement enregistrées sur votre compte ont été émises hors de l'UE, les paiements en crypto ne sont pas disponibles. Vous pouvez utiliser SOL, USDC ou EURC pour acheter des ERPC Credits. Utilisez ces ERPC Credits pour activer ou continuer les plans ERPC. Ouvrez le dashboard, choisissez le paiement crypto, effectuez le transfert depuis votre wallet, puis le dashboard vérifiera la transaction et créditera votre compte. Pays pris en charge : Allemagne, Autriche, Belgique, Bulgarie, Chypre, Croatie, Danemark, Espagne, Estonie, Finlande, France, Grèce, Hongrie, Irlande, Italie, Lettonie, Lituanie, Luxembourg, Malte, Pays-Bas, Pologne, Portugal, Roumanie, Slovaquie, Slovénie, Suède, Tchéquie. Pour les pays qui ne figurent pas dans cette liste, veuillez payer par carte bancaire. [ERPC Web Dashboard](https://dashboard.erpc.global/fr) ## Q. Comment puis-je obtenir la latence la plus faible possible? Nous vous recommandons vivement de combiner un nœud gRPC dédié avec notre [serveur bare metal](https://erpc.global/fr/baremetal/). Tous deux partagent le même réseau, permettant une communication privée à distance zéro sans traverser Internet. Cette configuration atteint une latence extrêmement faible, généralement avec des pings d'environ 0,1 ms. Veuillez nous contacter via l'ERPC Web Dashboard pour plus de détails. [ERPC Web Dashboard](https://dashboard.erpc.global/fr) 🔗 [ERPC Web Dashboard](https://dashboard.erpc.global/fr) ## Q. Qu'en est-il de la latence? La latence varie selon la méthode de mesure et votre environnement d'utilisation spécifique. Plutôt que de se concentrer sur des valeurs numériques exactes, il est crucial de s'assurer que la latence répond à vos besoins opérationnels réels. Nous fournissons des outils simples en TypeScript et Rust pour mesurer la latence. - [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream) - [SLV (français)](https://slv.dev/fr) ## Q. Ce RPC (gRPC, Shreds) est-il plus rapide que les autres? Nous concevons chaque niveau d'offre pour la vitesse, et nous sommes heureux d'être comparés côte à côte avec n'importe quel autre fournisseur. Les résultats peuvent varier selon la région, selon que vous utilisez un endpoint partagé ou dédié, selon le protocole (WebSockets, gRPC ou Shreds) et selon le langage de programmation de votre client. Si notre service vous semble plus lent, indiquez-nous via l'ERPC Web Dashboard les conditions précises et les concurrents auxquels vous l'avez comparé. Nous en identifierons la cause et améliorerons encore la vitesse. [ERPC Web Dashboard](https://dashboard.erpc.global/fr) ## Q. Quel plan est le plus rapide? En général, notre plan le plus haut de gamme offre les meilleures performances grâce à des CPU plus puissants, davantage de mémoire et des configurations matérielles plus robustes. Nous proposons aussi des solutions personnalisées si vous avez besoin de serveurs encore plus puissants, mais nos plans standard sont conçus pour offrir un rapport prix/performance optimal. Nous sommes convaincus d'offrir des performances de classe mondiale à chaque niveau de prix. Si vous trouvez un fournisseur plus rapide dans la même gamme de prix, merci de nous le signaler afin que nous puissions analyser la situation et apporter des améliorations. ## Q. J'ai une latence élevée. Que puis-je faire? La latence dépend fortement de votre proximité avec l'endpoint. Nous vous recommandons d'accéder depuis un serveur situé près de l'endpoint fourni. Les connexions les plus rapides sont réalisées avec notre [serveur bare metal](https://erpc.global/fr/baremetal/) et notre [service VPS](https://erpc.global/fr/vps/). ## Q. Quel est le plus rapide: WebSockets, gRPC ou Shreds? Les commentaires de nos clients classent systématiquement la vitesse comme suit: **Shreds > gRPC > WebSockets** Veuillez partager votre expérience si vous observez des résultats différents. ## Q. La latence ne correspond pas à mes attentes. La performance varie selon le langage de programmation utilisé. En général, la vitesse des langages se classe comme suit: **Rust > Go > TypeScript (JavaScript) > Python** Pour des comparaisons détaillées, voir: [Comparaison de la vitesse des langages de programmation](https://niklas-heer.github.io/speed-comparison/) Pour une performance maximale, nous vous recommandons fortement d'utiliser Rust.