FAQ - Stream Geyser gRPC

Q. In quali regioni si trovano i vostri nodi?

• Francoforte (FRA)
• Amsterdam (AMS)
• Londra (LON)
• New York (NY)
• Tokyo (TY)
• Singapore (SGP)
• Sydney (SYD)

Q. La latenza mostra 9999ms e viene selezionata una regione non ottimale. Cosa devo fare?

Q. Ho inserito il mio IP nell’allowlist, ma non riesco ancora a connettermi. Cosa devo controllare?

• Endpoint HTTPS: usa l’endpoint selezionato nella Dashboard sulla porta 443.
• Endpoint HTTP: usa l’endpoint selezionato nella Dashboard sulla porta 80.
• Usa l’URL mostrato nella Dashboard con https:// o http://.

Q. Ho usato solo WebSocket finora. Posso usare gRPC? Avete degli esempi?

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

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

Q. Posso registrare due indirizzi IP?

Q. Ci sono limiti sui filtri?

Q. Come raccolgo un errore gRPC prima di riconnettermi?

Q. Quali errori gRPC mettono in pausa la mia connessione e quando il mio client deve smettere di riconnettersi?

• Ogni richiesta Subscribe che ERPC rifiuta con ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS o STREAM_GUARD_SHAPE_ACCOUNTS_ALL, compresa la prima. Il primo errore conteggiato è l’avviso, che non avvia alcuna pausa.
• STREAM_GUARD_SLOW_READER. Tuttavia, se il ritardo di consegna nasce dal lato di ERPC, ERPC chiude lo stream senza che la chiusura venga conteggiata, e l’errore non riporta alcuna scadenza di retry.

• Avviso: nessuna pausa.
• Pausa di 60 secondi.
• Pausa di 300 secondi.
• Pausa di 1800 secondi.
• Pausa di 86400 secondi (24 ore). Questo è l’ultimo passo: qui ogni errore conteggiato avvia un’altra pausa di 86400 secondi.

• L’errore che avvia una pausa riporta Retry after N seconds. e gli header x-erpc-retry-after-seconds e x-erpc-retry-at (secondi Unix). L’avviso non riporta alcuna scadenza di retry.
• Quando una richiesta rifiutata conteggiata è quella che avvia una pausa, viene restituita come STREAM_GUARD_SHAPE_REJECT_PENALTY con ResourceExhausted (8) invece del proprio codice.
• Durante una pausa per lettore lento o egress, una riconnessione riceve STREAM_GUARD_PENALTY_ACTIVE con il tempo rimanente.
• Durante una pausa avviata da una richiesta rifiutata, una nuova connessione viene chiusa immediatamente, senza stato gRPC né codice ERPC. Una richiesta su una connessione ancora aperta può ricevere di nuovo come risposta STREAM_GUARD_SHAPE_REJECT_PENALTY con il tempo rimanente prima che quella connessione venga chiusa. Il client potrebbe non vedere mai più l’ora di fine, quindi deve salvare x-erpc-retry-at dal primo errore che lo riporta.

Q. Cosa significa STREAM_GUARD_SLOW_READER con ResourceExhausted (8) quando un ricevitore lento viene disconnesso?

Q. Perché il mio stream gRPC resta a una velocità costante e rimane indietro?

• Finestra di stream di 16 KiB: piatta intorno a 2.7 MB/s (16 KiB divisi per 6 ms); il ritardo di consegna è cresciuto di circa 0.6 secondi al secondo, arrivando a 26 secondi in 45 secondi.
• Entrambe a 16 MiB: il ritardo di consegna massimo è stato di 14 ms.

1. Confronta la velocità e il ritardo di consegna dello stream con lo schema descritto sopra.
2. Misura il tempo di andata e ritorno. Moltiplica la velocità dello stream per il tempo di andata e ritorno per stimare la finestra (2.7 MB/s per 6 ms fa circa 16 KB).
3. Controlla se una delle due finestre del tuo client ha un valore piccolo, o se la crescita automatica (la libreria che amplia la finestra da sé) è disattivata.
4. Controlla il buffer di ricezione TCP. Su Linux, esegui sysctl net.ipv4.tcp_rmem net.core.rmem_max e verifica se la tua applicazione imposta SO_RCVBUF, che disattiva il dimensionamento automatico.
5. Controlla le finestre e i buffer di tutto ciò che si trova nel mezzo.
6. Se la velocità non ha un tetto e cresce solo il ritardo, è lenta l’elaborazione dopo la ricezione. La domanda «Cosa significa STREAM_GUARD_SLOW_READER con ResourceExhausted (8) quando un ricevitore lento viene disconnesso?» qui sopra spiega come limitare il ciclo di ricezione alla lettura e spostare il lavoro pesante in una coda limitata.

// Entrambe le finestre fisse a 16 MiB; lascia http2_adaptive_window disattivato.
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?;

// Entrambe le finestre fisse a 16 MiB; lascia http2_adaptive_window disattivato.
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?;

// Finestra adattiva disattivata, quindi si usano queste dimensioni fisse.
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})

// Finestra adattiva disattivata, quindi si usano queste dimensioni fisse.
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})

// Richiede @grpc/grpc-js 1.14 o versioni successive per ampliare entrambe le finestre.
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})

// Richiede @grpc/grpc-js 1.14 o versioni successive per ampliare entrambe le finestre.
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})

// Imposta entrambe; questo disattiva anche la crescita automatica della finestra.
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)

// Imposta entrambe; questo disattiva anche la crescita automatica della finestra.
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)

# Se le tue opzioni includono ("grpc.http2.bdp_probe", 0), rimuovi quella voce.
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])

# Se le tue opzioni includono ("grpc.http2.bdp_probe", 0), rimuovi quella voce.
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])

Q. Cosa significa STREAM_GUARD_EGRESS_BUDGET con ResourceExhausted (8)?

Q. Cosa significa STREAM_GUARD_PENALTY_ACTIVE con ResourceExhausted (8)?

Q. Cosa significa STREAM_GUARD_SHAPE_BLOCKS con PermissionDenied (7)?

Q. Cosa significa STREAM_GUARD_SHAPE_ACCOUNTS_ALL con PermissionDenied (7)?

Q. Cosa significa STREAM_GUARD_SHAPE_REJECT_PENALTY con ResourceExhausted (8)?

Q. Cosa significa STREAM_ADMISSION_LIMIT_REACHED con ResourceExhausted (8)?

Q. Cosa significa STREAM_ADMISSION_IP_NOT_ADMITTED con PermissionDenied (7)?

Q. Cosa significa STREAM_ADMISSION_SOURCE_UNAVAILABLE con Unavailable (14)?

Q. Cosa significa STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE con Unavailable (14)?

Q. Cosa significa ERPC_GRPC_INVALID_ARGUMENT con InvalidArgument (3)?

Q. Cosa significa ERPC_GRPC_REQUEST_FAILED quando gRPC restituisce un altro stato diverso da zero?

Q. Quale regione consigliate?

Q. Ho bisogno di una latenza di ~400ms o migliore.

• Comprensione realistica dei valori di ping: i valori di ping indicano condizioni ideali e non riflettono la latenza effettiva nelle comunicazioni in streaming, che tipicamente presentano una latenza pari a circa 5 volte quella del ping. Ad esempio, un ping di 100ms tra continenti si traduce realisticamente in circa 500ms di latenza. Pertanto, l’infrastruttura deve essere collocata nella stessa regione per raggiungere una latenza di ~400ms.
  • Valori di ping tipici di riferimento:
    • Stessa rete: ~0.1ms
    • Private Network Interconnect (PNI): ~0.2ms
    • Stesso data center: ~0.3ms
    • Stessa città: ~1ms
    • Paese vicino: ~5–10ms
    • Intercontinentale: ~100–300ms
• Evitare la trappola della latenza media: i validator Solana sono dispersi geograficamente in tutto il mondo e lo schedule dei leader cambia casualmente a ogni epoch. Affidarsi alla latenza media per raggiungere ~400ms non è praticabile. Devi invece tracciare con precisione gli schedule dei validator nella tua regione specifica per identificare gli slot con la latenza più bassa. Per ottenere costantemente la latenza minima, è necessaria un’infrastruttura in tutte le regioni rilevanti. Nella stessa regione, l’acquisizione dei dati può avvenire in decine di millisecondi e la trasmissione in pochi millisecondi.
• Tracciamento dello schedule dei leader: monitora lo schedule dei validator leader per la tua regione usando la ERPC Leader Slot API (getLeaderSlots). Restituisce lo schedule dei prossimi leader, il peso dello stake per l’epoch corrente, la geolocalizzazione stimata dei validator e i valori di ping di riferimento, così puoi individuare gli slot a latenza più bassa su cui puntare prima che arrivino. I dati pubblici in stile mappa e le API RPC native sono utili per una visibilità ampia della rete, ma non sono abbastanza precisi per il timing di esecuzione. La Leader Slot API colma questa lacuna con la granularità necessaria per le decisioni di routing e trading.
  • Documentazione ERPC Leader Slot API
  • ERPC Web Dashboard

Q. Come posso fare trading zero-block (zero-slot)?

• Identificare le zone di opportunità: i validator Solana sono distribuiti globalmente ed è fisicamente impossibile ottenere la latenza ottimale per ogni slot. Pertanto, monitora gli schedule dei leader dei validator nella regione in cui si trova la tua infrastruttura e identifica le zone di opportunità più favorevoli. Anche distribuire l’infrastruttura su più regioni può essere vantaggioso. Ad esempio, Francoforte è una regione chiave grazie alla sua elevata densità di validator, che si traduce in una selezione dei leader più frequente e maggiori opportunità di trading.
  Usa la ERPC Leader Slot API (getLeaderSlots) per consultare lo schedule dei prossimi leader, il peso dello stake per l’epoch corrente, i dati stimati di geolocalizzazione dei validator e i valori di ping di riferimento con una precisione di gran lunga superiore rispetto alle fonti di dati pubbliche in stile mappa o alle API RPC native. Questo ti permette di mappare le zone di opportunità prima che arrivino gli slot ed eseguire operazioni a latenza quasi zero.
  • Documentazione ERPC Leader Slot API
  • ERPC Web Dashboard
• Implementare nodi dedicati: se fatichi a competere, considera l’implementazione di nodi dedicati. I nodi condivisi subiscono latenza a causa del traffico di altri utenti e quindi non sono consigliati. Inoltre, collocare il tuo nodo dedicato nella stessa rete della tua applicazione riduce significativamente la latenza di rete e ottimizza le prestazioni.

Q. Posso usare un endpoint specifico?

Q. Ricevo un errore 401. Perché?

Q. Ricevo un errore 429. Perché?

Q. Perché gli endpoint dedicati sono più veloci?

Q. Il prezzo promozionale aumenterà dopo la sottoscrizione?

Q. Voglio pagare in crypto

Q. Come posso ottenere la latenza più bassa possibile?

Q. Com’è la latenza?

• Solana Stream SDK - ValidatorsDAO GitHub
• SLV (in inglese)

Q. Questo RPC (gRPC, Shreds) è più veloce degli altri?

Q. Quale piano offre le prestazioni più veloci?

Q. Riscontro una latenza elevata. Cosa posso fare?

Q. Qual è il più veloce: WebSockets, gRPC o Shreds?

Q. La latenza non è quella che mi aspettavo.