ERPC

FAQ - Geyser gRPC Stream

Q. Di region mana node Anda berada?

Saat ini kami mengoperasikan node di region berikut:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • New York (NY)
  • Tokyo (TY)
  • Singapura (SGP)
  • Sydney (SYD)
ERPC mengukur latensi jaringan yang sebenarnya berdasarkan jalur routing nyata, secara otomatis memilih region dengan latensi terendah daripada mengandalkan jarak garis lurus. Pendekatan ini tidak hanya meningkatkan latensi untuk masing-masing pengguna tetapi juga meningkatkan efisiensi jaringan secara keseluruhan dan memperkuat ketahanan global ERPC terhadap potensi serangan.
Jika lingkungan Anda tidak secara otomatis memilih region optimal, silakan hubungi kami melalui ERPC Web Dashboard.
ERPC Web Dashboard: https://dashboard.erpc.global/id

Q. Latensi menunjukkan 9999ms dan region yang tidak optimal terpilih. Apa yang harus saya lakukan?

Untuk pemilihan wilayah gRPC, ERPC mengirim probe latensi ICMP ke IP terdaftar Anda dari host proxy yang tercantum di bawah ini. Izinkan permintaan echo ICMP masuk dari setiap IP sumber yang tercantum. Jika diblokir oleh firewall (ufw, firewall cloud, grup keamanan, dll.), hasil pengukuran dapat menjadi 9999ms dan wilayah yang tidak optimal dapat terpilih. Beberapa IP dalam satu wilayah merupakan host probe yang terpisah; semuanya diperlukan.
RegionIP sumber ICMP
🇳🇱 Amsterdam82.21.43.34, 151.244.92.36
🇺🇸 New York151.243.244.5
🇩🇪 Frankfurt151.241.178.20, 151.241.178.34, 151.241.178.21
🇬🇧 London151.241.65.4
🇯🇵 Tokyo143.20.238.66
🇸🇬 Singapore151.245.186.2
🛰️ Far Point143.20.238.73

Q. Saya sudah mengizinkan IP, tetapi masih tidak bisa terhubung. Apa yang harus dicek?

Gunakan endpoint HTTPS terenkripsi yang dipilih di Dashboard. HTTPS memakai port 443; HTTP pada port 80 tetap menjadi opsi latensi rendah tanpa enkripsi.
Kedua transport menggunakan allowlist IP terdaftar yang sama. Gunakan endpoint yang dipilih di Dashboard: HTTPS pada 443 atau HTTP pada 80.
  • Endpoint HTTPS: gunakan endpoint pilihan Dashboard pada port 443.
  • Endpoint HTTP: gunakan endpoint pilihan Dashboard pada port 80.
  • Gunakan URL yang ditampilkan di Dashboard dengan https:// atau http://.
Autentikasi didasarkan pada alamat IP terdaftar Anda. Jangan tambahkan header x-token, token, atau Authorization kecuali halaman produk tertentu secara eksplisit memintanya.

Q. Saya sebelumnya hanya menggunakan WebSocket. Bisakah saya menggunakan gRPC? Apakah Anda punya sampel?

Ya. Anda dapat dengan cepat menguji dan mulai mengembangkan dengan gRPC menggunakan SLV.
Untuk endpoint bersama yang dapat Anda uji tanpa token, jalankan:
bash
slv check grpc --endpoint <YOUR_ENDPOINT> --token none
Lihat Panduan gRPC Quickstart kami untuk detailnya.

Q. Bisakah saya mendaftarkan dua alamat IP?

Anda dapat menggunakan satu endpoint per langganan. Jika Anda ingin menggunakan dua alamat IP, Anda harus memiliki dua langganan terpisah.

Q. Apakah ada batasan filter?

Shared Geyser gRPC memiliki perlindungan penggunaan wajar agar satu stream tidak memakai sumber daya yang dibutuhkan pelanggan ERPC lain. Pada aturan Shared saat ini, setiap map blocks yang tidak kosong ditolak, termasuk permintaan block yang sempit. Setiap filter account harus memuat account, owner, atau filter cuckoo yang didukung; hanya memcmp atau dataSize tidak cukup.
Hapus shape yang ditolak dan subscribe hanya data yang diperlukan aplikasi Anda. Subscription transaksi atau metadata block dapat memenuhi kebutuhan tanpa membawa block penuh. Dedicated Geyser gRPC sesuai bila workload yang sah melampaui shape atau allowance sumber daya Shared; layanan itu tidak membuat parameter tidak valid menjadi valid atau memperbaiki client yang lambat.

Q. Bagaimana mengumpulkan error gRPC sebelum menyambung ulang?

Simpan error pertama sebelum loop reconnect menggantikannya. Catat status dan pesan gRPC dari metadata awal dan trailer, beserta x-erpc-error-code, x-erpc-error-reason, dan x-erpc-doc-url. Bila ERPC memberi pause, catat juga x-erpc-retry-after-seconds dan x-erpc-retry-at (detik Unix).
Error dapat ditampilkan sebagai ERPC [STREAM_GUARD_SLOW_READER]: .... Tempel error yang ditampilkan atau kodenya ke pencarian FAQ. Untuk penjelasan kanonis, gunakan FAQ gRPC ERPC. Jangan menganggap trailer selalu diterima saat koneksi berakhir lebih awal.
Anda juga dapat mencari berdasarkan gejala: slow receiver, disconnected, bandwidth, delivery lag, backlog, pause, retry, invalid argument, resource exhausted, permission denied, IP registration, too many streams, full blocks, atau all accounts.

Q. Error gRPC mana yang memicu pause pada koneksi saya, dan kapan client saya harus berhenti melakukan reconnect?

Pause adalah periode dengan batas waktu yang ditetapkan ERPC setelah error tertentu. Client tidak boleh reconnect selama pause aktif.
Yang dihitung. Error berikut dihitung, dan semuanya berbagi satu urutan langkah yang sama:
  • Setiap request Subscribe yang ditolak ERPC dengan ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS atau STREAM_GUARD_SHAPE_ACCOUNTS_ALL, termasuk yang pertama. Error terhitung pertama adalah peringatan, yang tidak memulai pause.
  • STREAM_GUARD_SLOW_READER. Namun, bila delivery lag muncul di sisi ERPC, ERPC menutup stream tanpa menghitungnya, dan error tidak membawa waktu retry.
Yang tidak dihitung: reconnect itu sendiri, keempat kode STREAM_ADMISSION_* (STREAM_ADMISSION_LIMIT_REACHED, STREAM_ADMISSION_IP_NOT_ADMITTED, STREAM_ADMISSION_SOURCE_UNAVAILABLE dan STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE), serta setiap error terhitung yang terjadi selama pause aktif. Error terhitung selama pause tidak memperpanjang pause dan tidak berpindah ke langkah berikutnya.
Urutan langkah. Setiap error terhitung memajukan satu langkah dalam urutan ini, dimulai dari peringatan:
  • Peringatan: tanpa pause.
  • Pause 60 detik.
  • Pause 300 detik.
  • Pause 1800 detik.
  • Pause 86400 detik (24 jam). Ini adalah langkah terakhir: pada langkah ini, setiap error terhitung memulai pause 86400 detik yang baru.
Pada langkah peringatan, error terhitung berikutnya berpindah ke pause 60 detik hanya jika datang dalam 1 jam sejak peringatan. Error terhitung yang datang lebih dari 1 jam setelah peringatan menjadi peringatan lain tanpa pause, dan jendela 1 jam kemudian berjalan sejak peringatan baru tersebut.
Error terhitung yang datang kurang dari 60 detik setelah error terakhir yang dihitung dihitung sebagai bagian dari error tersebut dan tidak memajukan langkah apa pun.
Kapan langkah kembali ke peringatan. Setelah langkah-langkah ini memulai pause, langkah kembali ke peringatan hanya setelah 24 jam tanpa error terhitung dan tanpa pause, diukur dari akhir pause terakhir; error terhitung berikutnya setelah itu menjadi peringatan tanpa pause. Sebelum itu, error terhitung berikutnya langsung memulai langkah berikutnya, tanpa peringatan.
Pause egress. STREAM_GUARD_EGRESS_BUDGET memulai pause tetap tersendiri selama 600 detik. Kode ini tidak memajukan langkah.
Di mana waktu berakhir dicantumkan.
  • Error yang memulai pause membawa Retry after N seconds. serta header x-erpc-retry-after-seconds dan x-erpc-retry-at (detik Unix). Peringatan tidak membawa waktu retry.
  • Bila request yang ditolak dan terhitung adalah yang memulai pause, penolakannya dikembalikan sebagai STREAM_GUARD_SHAPE_REJECT_PENALTY dengan ResourceExhausted (8), bukan dengan kodenya sendiri.
  • Selama pause slow-reader atau egress, reconnect mendapat STREAM_GUARD_PENALTY_ACTIVE beserta sisa waktu.
  • Selama pause yang dimulai oleh request yang ditolak, koneksi baru langsung ditutup tanpa status gRPC dan tanpa kode ERPC. Request pada koneksi yang masih terbuka dapat dijawab lagi dengan STREAM_GUARD_SHAPE_REJECT_PENALTY beserta sisa waktu sebelum koneksi tersebut ditutup. Client mungkin tidak akan pernah melihat waktu berakhir lagi, jadi client harus menyimpan x-erpc-retry-at dari error pertama yang membawanya.
KodeStatus gRPCMemulai atau memajukan pause?Yang harus dilakukan client
ERPC_GRPC_INVALID_ARGUMENTInvalidArgument (3)Ya, bila menolak request Subscribe. Saat itu ini adalah error terhitung menurut langkah di atas.Hentikan loop dan jangan kirim ulang request yang sama. Entri khususnya di bawah mencantumkan hal yang perlu diperiksa.
STREAM_GUARD_SHAPE_BLOCKSPermissionDenied (7)Ya. Ini adalah error terhitung menurut langkah di atas.Hentikan loop dan jangan kirim ulang request yang sama. Entri khususnya di bawah mencantumkan hal yang perlu diperiksa.
STREAM_GUARD_SHAPE_ACCOUNTS_ALLPermissionDenied (7)Ya. Ini adalah error terhitung menurut langkah di atas.Hentikan loop dan jangan kirim ulang request yang sama. Entri khususnya di bawah mencantumkan hal yang perlu diperiksa.
STREAM_GUARD_SLOW_READERResourceExhausted (8)Ya. Ini adalah error terhitung menurut langkah di atas. Namun, bila delivery lag muncul di sisi ERPC, ERPC menutup stream tanpa menghitungnya, dan error tidak membawa waktu retry.Hentikan loop. Entri khususnya di bawah mencantumkan hal yang perlu diperiksa. Jika error ini memulai pause, jangan reconnect sebelum waktu di x-erpc-retry-at.
STREAM_GUARD_EGRESS_BUDGETResourceExhausted (8)Ya. Kode ini memulai pause tetap 600 detik di luar langkah di atas.Jangan reconnect sebelum waktu di x-erpc-retry-at. Entri khususnya di bawah mencantumkan hal yang perlu diperiksa.
STREAM_GUARD_SHAPE_REJECT_PENALTYResourceExhausted (8)Ya. Ini adalah request yang ditolak dan terhitung yang memulai pause. Kode ini dapat kembali lagi beserta sisa waktu pada koneksi yang masih terbuka.Jangan reconnect sebelum waktu di x-erpc-retry-at. Perbaiki request yang ditolak dan jangan mengirimnya ulang tanpa perubahan.
STREAM_GUARD_PENALTY_ACTIVEResourceExhausted (8)Tidak. Kode ini melaporkan pause slow-reader atau egress yang sudah aktif.Jangan reconnect sebelum waktu di x-erpc-retry-at.
STREAM_ADMISSION_LIMIT_REACHEDResourceExhausted (8)Tidak. Kode ini tidak memiliki pause berbatas waktu.Tutup stream yang tidak digunakan, lalu retry.
STREAM_ADMISSION_IP_NOT_ADMITTEDPermissionDenied (7)Tidak. Kode ini tidak memiliki pause berbatas waktu.Entri khususnya di bawah mencantumkan hal yang perlu diperiksa.
STREAM_ADMISSION_SOURCE_UNAVAILABLEUnavailable (14)Tidak. Kode ini tidak memiliki pause berbatas waktu.Lakukan backoff seperti biasa dan coba lagi setelah jeda.
STREAM_ADMISSION_SNAPSHOT_UNAVAILABLEUnavailable (14)Tidak. Kode ini tidak memiliki pause berbatas waktu.Lakukan backoff seperti biasa dan coba lagi setelah jeda.
Yang harus dilakukan client. Saat terjadi error terhitung, hentikan loop, jangan kirim ulang request yang sama, dan perbaiki request tersebut. Selama pause, jangan reconnect sebelum waktu di x-erpc-retry-at. Request Subscribe yang ditolak dihitung menurut aturan di atas, sedangkan reconnect tidak.

Q. Apa arti STREAM_GUARD_SLOW_READER dengan ResourceExhausted (8) ketika slow receiver terputus?

ERPC mengamati write progress yang tidak memadai atau delivery lag pada stream ini. Delivery lag saja tidak dapat menentukan penyebabnya. Periksa kehilangan jaringan, bandwidth efektif, perangkat keras host, serta apakah consumer aplikasi dapat mengimbangi. Sempitkan data yang disubscribe dan pindahkan pemrosesan dari receive loop ke bounded queue. Bounded queue mengendalikan pemakaian memori, tetapi tidak dapat memperbaiki consumer yang terus-menerus lambat. Bila ERPC memberikan deadline retry, tunggu sebelum reconnect. Pertanyaan “Mengapa stream gRPC saya tertahan di kecepatan yang sama dan tertinggal?” di bawah menjelaskan receive window dan cara memperbesarnya di library client Anda.

Q. Mengapa stream gRPC saya tertahan di kecepatan yang sama dan tertinggal?

Receive window yang kecil di client Anda, atau di sesuatu yang berada di antara client dan ERPC, dapat menyebabkan stream diputus dengan STREAM_GUARD_SLOW_READER dan pause yang menyusul. Jawaban ini menjelaskan apa itu receive window, cara mengetahui apakah receive window membatasi stream Anda, dan cara memperbesarnya per library. Pertanyaan “Error gRPC mana yang memicu pause pada koneksi saya, dan kapan client saya harus berhenti melakukan reconnect?” di atas menjelaskan langkah-langkahnya beserta durasinya.
Apa itu receive window. Di HTTP/2, penerima memberi tahu pengirim berapa banyak data yang boleh dikirim sebelum penerima mengonfirmasi; jumlah itu adalah receive window (HTTP/2 flow control window). Satu kali pulang-pergi membawa paling banyak satu window, sehingga kecepatan mentok di sekitar window dibagi waktu pulang-pergi (perjalanan ke endpoint dan kembali).
Batas lainnya. Ada dua window, satu per stream dan satu per koneksi (semua stream pada satu koneksi berbagi window ini), dan yang lebih kecil menentukan batasnya. Dalam spesifikasi HTTP/2, kedua window dimulai dari 65.535 byte. TCP receive buffer (memori untuk data yang masuk) membatasi kecepatan dengan cara yang sama. Proxy, load balancer, gateway, VPN, atau sidecar di antara client Anda dan ERPC memiliki window dan buffer sendiri. Window atau buffer yang kecil di sana membatasi stream meskipun window client Anda sendiri besar.
Seperti apa tampaknya. Satu stream tertahan di kecepatan yang hampir sama, sesibuk apa pun chain-nya, dan delivery lag-nya terus bertambah. ERPC mengukur dari lokasi dengan waktu pulang-pergi sekitar 6 ms ke endpoint Shared di Frankfurt, dengan hanya mengubah window di antara setiap percobaan:
  • Stream window 16 KiB: datar di sekitar 2.7 MB/s (16 KiB dibagi 6 ms); delivery lag bertambah sekitar 0.6 detik per detik, hingga mencapai 26 detik dalam 45 detik.
  • Keduanya 16 MiB: delivery lag maksimum adalah 14 ms.
Bila delivery lag muncul di sisi ERPC, ERPC menutup stream tanpa menghitungnya, dan error tidak membawa waktu retry.
Cara mengeceknya.
  1. Bandingkan kecepatan dan delivery lag stream dengan pola di atas.
  2. Ukur waktu pulang-pergi. Kalikan kecepatan stream dengan waktu pulang-pergi untuk memperkirakan window (2.7 MB/s dikali 6 ms kira-kira 16 KB).
  3. Periksa apakah salah satu dari dua window client Anda bernilai kecil, atau apakah pertumbuhan otomatis (library memperbesar window sendiri) dimatikan.
  4. Periksa TCP receive buffer. Di Linux, jalankan sysctl net.ipv4.tcp_rmem net.core.rmem_max, dan lihat apakah aplikasi Anda mengatur SO_RCVBUF, yang mematikan penentuan ukuran otomatis.
  5. Periksa window dan buffer dari apa pun yang berada di antara client Anda dan ERPC.
  6. Bila kecepatan tidak punya batas atas dan hanya lag yang bertambah, yang lambat adalah pemrosesan setelah data diterima. Pertanyaan “Apa arti STREAM_GUARD_SLOW_READER dengan ResourceExhausted (8) ketika slow receiver terputus?” di atas menjelaskan cara membatasi receive loop hanya untuk membaca dan memindahkan pekerjaan berat ke bounded queue.
Pengaturan per library. Contoh-contoh ini mengatur kedua window ke 16 MiB, seperti pada pengukuran ERPC. Untuk library yang tidak tercantum, cari pengaturan initial window HTTP/2.
Rust, yellowstone-grpc-client. Tanpa pengaturan window, GeyserGrpcClient::build_from_shared memakai 2 MiB per stream dan 5 MiB per koneksi. Pada waktu pulang-pergi 6 ms, nilai default ini memungkinkan lebih dari 300 MB/s, sehingga tidak membatasi stream. Untuk mengatur window sendiri, gunakan dua method builder dan biarkan http2_adaptive_window mati. Jika opsi itu menyala, window dimulai dari 65.535 byte dan tumbuh sendiri hingga 16 MiB, mengabaikan nilai Anda.
rust
// Kedua window ditetapkan 16 MiB; biarkan http2_adaptive_window mati.
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 atau lebih baru. Default: 4 MiB per stream, 8 MiB per koneksi, pertumbuhan otomatis menyala. Window dimulai dari 64 KiB dan tumbuh hingga 16 MiB, sehingga nilai default jarang membatasi stream. Untuk menetapkan ukurannya, berikan argumen ketiga dengan grpcHttp2AdaptiveWindow: false.
typescript
// Adaptive window mati, sehingga ukuran tetap ini yang dipakai.
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})
TypeScript, @triton-one/yellowstone-grpc 5.0.0 atau lebih lama. Versi ini memakai @grpc/grpc-js, yang window default-nya 65.535 byte: sekitar 11 MB/s pada 6 ms, sekitar 0.66 MB/s pada 100 ms. Mulai versi 1.14, @grpc/grpc-js menerapkan 'grpc-node.flow_control_window' ke kedua window; versi 1.13 hanya menerapkannya ke stream window, sehingga connection window tetap 65.535 byte (sekitar 11 MB/s pada 6 ms). Jika versi @grpc/grpc-js lebih lama dari 1.14, upgrade ke @triton-one/yellowstone-grpc 5.0.1 atau lebih baru adalah cara yang lebih cepat.
typescript
// Memerlukan @grpc/grpc-js 1.14 atau lebih baru untuk memperbesar kedua window.
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})
Go, google.golang.org/grpc. Secara default, library memperbesar window sendiri, hingga 16 MiB. grpc.WithInitialWindowSize dan grpc.WithInitialConnWindowSize menetapkan ukurannya dan mematikan pertumbuhan otomatis; nilai di bawah 64 KiB diabaikan. Atur keduanya: jika hanya satu yang diatur, window yang lain tetap 64 KiB.
go
// Atur keduanya; ini juga mematikan pertumbuhan window otomatis.
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)
Python, grpcio. grpc.http2.bdp_probe menyala secara default, sehingga window tumbuh sendiri; jika kode Anda mengirim ("grpc.http2.bdp_probe", 0), hapus itu. grpc.http2.lookahead_bytes mengatur read-ahead per stream (default 64 KB); nilai yang lebih besar dapat membantu pada waktu pulang-pergi yang panjang.
python
# Jika opsi Anda berisi ("grpc.http2.bdp_probe", 0), hapus entri itu.
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])
Terima dari lokasi yang lebih dekat. Waktu pulang-pergi yang lebih singkat membuat window yang sama mengantarkan lebih banyak data, dan layanan VPS serta server Bare-Metal ERPC menempatkan client di dekat endpoint.
Bagi dengan hati-hati. Standard mengizinkan 10 stream dan Premium 50, per source IP yang terdaftar. Setiap stream mendapat stream window sendiri, tetapi stream pada satu koneksi berbagi satu connection window, sehingga connection window yang kecil tetap membatasi kecepatan. Saat mengganti stream, tutup stream lama terlebih dahulu: stream yang terbuka termasuk dalam batas, dan melampauinya mengembalikan STREAM_ADMISSION_LIMIT_REACHED (pertanyaannya sendiri ada di bawah). Membagi stream tidak mempercepat pemrosesan yang lambat.

Q. Apa arti STREAM_GUARD_EGRESS_BUDGET dengan ResourceExhausted (8)?

Traffic agregat dari IP melampaui allowance Shared, sehingga stream terkait dapat tertutup bersamaan. Kurangi volume data dan stream paralel yang tidak perlu, lalu tunggu hingga deadline yang dikembalikan. Pause egress ini tetap 600 detik dan tidak menaikkan penalty ladder, walaupun pause yang sudah ada dan lebih panjang dapat tetap berlaku.

Q. Apa arti STREAM_GUARD_PENALTY_ACTIVE dengan ResourceExhausted (8)?

Pause slow-reader atau egress sebelumnya masih aktif, dan response ini membawa sisa waktu. Simpan error ERPC pertama, perbaiki penyebabnya, dan jangan reconnect sebelum x-erpc-retry-at; jangan reconnect lebih awal untuk mengujinya. Upaya reconnect tidak dihitung. Pertanyaan “Error gRPC mana yang memicu pause pada koneksi saya, dan kapan client saya harus berhenti melakukan reconnect?” di atas menjelaskan langkah-langkahnya beserta durasinya.

Q. Apa arti STREAM_GUARD_SHAPE_BLOCKS dengan PermissionDenied (7)?

Aturan Shared saat ini menolak setiap map blocks yang tidak kosong, bahkan saat request sempit. Hapus map blocks. Gunakan transactions dan/atau metadata block bila memenuhi kebutuhan, tetapi keduanya bukan padanan block penuh. Gunakan Dedicated Geyser gRPC bila membutuhkan full blocks; ini tidak berarti tersedia paket Shared selective-block.

Q. Apa arti STREAM_GUARD_SHAPE_ACCOUNTS_ALL dengan PermissionDenied (7)?

Entri filter account harus memilih data dengan account, owner, atau filter cuckoo yang didukung. memcmp dan dataSize saja tidak cukup. Sempitkan request account ke salah satu shape yang didukung tersebut, atau gunakan Dedicated Geyser gRPC bila memerlukan full account stream.

Q. Apa arti STREAM_GUARD_SHAPE_REJECT_PENALTY dengan ResourceExhausted (8)?

Kode ini dikembalikan sebagai pengganti ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS atau STREAM_GUARD_SHAPE_ACCOUNTS_ALL bila request yang ditolak dan terhitung itu adalah yang memulai pause; pertanyaan “Error gRPC mana yang memicu pause pada koneksi saya, dan kapan client saya harus berhenti melakukan reconnect?” di atas menjelaskan kapan hal itu terjadi. Kode ini membawa Retry after N seconds., x-erpc-retry-after-seconds dan x-erpc-retry-at. Selama pause ini, koneksi baru langsung ditutup tanpa status gRPC dan tanpa kode ERPC, sehingga client mungkin tidak akan pernah melihat waktu berakhir lagi. Simpan x-erpc-retry-at dari error pertama yang membawanya. Request Subscribe yang ditolak dihitung menurut aturan di atas, sedangkan reconnect tidak. Perbaiki request dan jangan mengirimnya ulang tanpa perubahan. Koneksi yang putus dini dapat terlihat seperti transport error, jadi simpan error ERPC pertama sebelum loop reconnect menyembunyikannya.

Q. Apa arti STREAM_ADMISSION_LIMIT_REACHED dengan ResourceExhausted (8)?

Allowance admission saat ini penuh. Tutup stream yang tidak digunakan atau duplikat, periksa allowance untuk koneksi tersebut, dan retry setelah kapasitas tersedia. Response ini sendiri tidak berarti timed penalty sedang aktif.

Q. Apa arti STREAM_ADMISSION_IP_NOT_ADMITTED dengan PermissionDenied (7)?

ERPC tidak dapat menerima koneksi, termasuk setelah masa tenggang registration IP berakhir. Bandingkan IP outbound aktual dengan IP yang terdaftar dan konfirmasi access state saat ini. Biarkan perubahan registration menyebar tanpa mengasumsikan waktu propagasi tertentu, lalu hubungi support bila kondisi berlanjut.

Q. Apa arti STREAM_ADMISSION_SOURCE_UNAVAILABLE dengan Unavailable (14)?

ERPC tidak dapat menentukan source koneksi ini saat itu. Lakukan backoff dan coba lagi setelah jeda. Bila tetap terjadi, hubungi support dengan error pertama dan metadatanya; response ini tidak membuktikan adanya fault pada network atau server pelanggan.

Q. Apa arti STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE dengan Unavailable (14)?

ERPC tidak dapat memverifikasi access saat itu. Lakukan backoff dan coba lagi setelah jeda, lalu hubungi support jika berlanjut. Mendaftarkan ulang berulang kali, memperluas filter, atau membeli Dedicated Geyser gRPC tidak memperbaiki response availability ini.

Q. Apa arti ERPC_GRPC_INVALID_ARGUMENT dengan InvalidArgument (3)?

Request berisi parameter, opsi, tipe field, key, atau kombinasi filter yang tidak valid. Perbaiki request sebelum retry, dan jangan kirim ulang request yang sama. Setiap request Subscribe yang ditolak dengan kode ini adalah error terhitung menurut aturan pause dalam pertanyaan “Error gRPC mana yang memicu pause pada koneksi saya, dan kapan client saya harus berhenti melakukan reconnect?” di atas; aturan yang sama berlaku untuk STREAM_GUARD_SHAPE_BLOCKS, STREAM_GUARD_SHAPE_ACCOUNTS_ALL dan STREAM_GUARD_SLOW_READER. Bila salah satu request tersebut memulai pause, penolakannya dikembalikan sebagai STREAM_GUARD_SHAPE_REJECT_PENALTY dengan ResourceExhausted (8). Dedicated Geyser gRPC tidak membuat parameter tidak valid menjadi valid.
Pesan error mengakhiri kode dengan (reason: <token>), dan token yang sama dikembalikan di response header x-erpc-error-reason. Cari token di bawah untuk melihat apa yang perlu diubah. Jika ada batas yang berlaku, pesan error menyebutkannya.
ReasonArtinyaYang perlu diubah
too_many_filtersRequest membawa lebih banyak filter bernama atau data slice daripada yang boleh ada dalam satu request.Gunakan lebih sedikit filter bernama (atau data slice) jenis ini per request.
empty_filterSebuah filter tidak memiliki address, dan filter kosong berarti semuanya.Beri setiap filter minimal satu address (account: sebuah account atau owner; transaksi: daftar account). Shared gRPC tidak melayani filter kosong.
too_many_addressesSatu field filter berisi terlalu banyak address.Gunakan lebih sedikit address dalam satu field filter; bagi ke beberapa filter atau persempit daftarnya.
address_not_allowedSebuah filter menyebut address yang tidak diizinkan Shared gRPC.Hapus address bervolume tinggi itu dari filter.
filter_name_too_longNama filter terlalu panjang.Gunakan nama filter yang lebih pendek (key map).
invalid_commitmentLevel commitment tidak valid.Gunakan processed, confirmed, atau finalized.
invalid_addressSebuah filter berisi address yang tidak valid.Pastikan setiap address adalah address Solana base58 yang valid (tanpa string kosong, spasi, atau panjang yang salah).
invalid_signatureNilai signature transaksi tidak valid.Gunakan signature transaksi base58 yang valid.
invalid_account_data_filterFilter data account tidak valid.Perbaiki filter memcmp, datasize, dan data token account, dan jaga jumlahnya dalam batas yang disebut di pesan.
invalid_data_sliceData slice tidak valid.Urutkan data slice berdasarkan offset dan jangan biarkan saling tumpang tindih.
blocks_include_not_allowedOpsi subscription blocks tidak tersedia di Shared gRPC.Hilangkan blocks dan gunakan subscription transaksi atau blocks_meta.
invalid_token_accounts_modeMode token accounts tidak valid.Gunakan ALL (0) atau BALANCE_CHANGED (1).
invalid_argumentTidak ada alasan di atas yang berlaku.Periksa filter dan parameter request sebelum mencoba lagi.

Q. Apa arti ERPC_GRPC_REQUEST_FAILED saat gRPC mengembalikan status bukan nol lainnya?

Request gagal dengan status gRPC valid yang menentukan langkah berikutnya. Perbaiki request untuk status seperti OutOfRange (11) bila history range tidak valid; lakukan backoff untuk status availability seperti Unavailable (14). Jangan menganggap setiap status non-zero bersifat transient atau melakukan retry setiap response tanpa perubahan.

Q. Region mana yang Anda rekomendasikan?

Tidak ada satu region terbaik yang permanen. Solana bersifat global, dan peran pemimpin berpindah di antara validator sesuai jadwal pemimpin. Region dengan lebih banyak validator dan stake yang lebih tinggi mendapatkan slot pemimpin lebih sering, yang dapat membantu transaksi mendarat lebih cepat. Trade-off-nya adalah lalu lintas yang bersaing juga terkonsentrasi di sana, sehingga region yang kurang ramai terkadang dapat memberikan hasil yang lebih baik tergantung pada strategi Anda.
Sebagai titik awal yang praktis, pilih region padat validator seperti Frankfurt atau Pantai Timur AS ketika pasokan slot pemimpin yang stabil paling penting, atau tempatkan diri Anda dekat dengan validator target tertentu ketika eksekusi jalur terpendek menjadi prioritas. Gunakan Validators Solutions untuk memahami distribusi jaringan Solana publik, lalu gunakan ERPC Leader Slot API dan pengukuran nyata untuk memutuskan apakah deployment region tunggal, region ganda, atau global yang sesuai.
Laporan Distribusi Mainnet Solana

Q. Saya membutuhkan latensi ~400ms atau lebih baik.

Untuk mencapai latensi dalam batas sekitar 400ms, pertimbangkan poin-poin penting berikut:
  • Pemahaman Realistis tentang Nilai Ping: Nilai ping menunjukkan kondisi ideal dan tidak mencerminkan latensi aktual dalam komunikasi streaming, yang biasanya mencapai sekitar 5 kali latensi ping. Sebagai contoh, ping 100ms antarbenua secara realistis menghasilkan latensi sekitar 500ms. Oleh karena itu, infrastruktur harus dibangun dalam region yang sama untuk mencapai latensi ~400ms.
    • Referensi Nilai Ping Tipikal:
      • Jaringan yang sama: ~0.1ms
      • Private Network Interconnect (PNI): ~0.2ms
      • Pusat data yang sama: ~0.3ms
      • Kota yang sama: ~1ms
      • Negara tetangga: ~5–10ms
      • Antarbenua: ~100–300ms
  • Menghindari Jebakan Latensi Rata-rata: Validator Solana tersebar secara geografis di seluruh dunia, dan jadwal pemimpin berubah secara acak pada setiap epoch. Mengandalkan latensi rata-rata untuk mencapai ~400ms tidak praktis. Sebaliknya, Anda harus melacak jadwal validator secara tepat di region spesifik Anda untuk mengidentifikasi slot dengan latensi terendah. Untuk secara konsisten mencapai latensi minimal, diperlukan infrastruktur di seluruh region yang relevan. Dalam region yang sama, akuisisi data dapat terjadi dalam puluhan milidetik, sementara transmisi dapat berlangsung hanya dalam beberapa milidetik.
  • Melacak Jadwal Pemimpin: Pantau jadwal validator pemimpin untuk region Anda menggunakan ERPC Leader Slot API (getLeaderSlots). API ini mengembalikan jadwal pemimpin yang akan datang, bobot stake untuk epoch saat ini, perkiraan geolokasi validator, dan nilai ping referensi, sehingga Anda dapat mengidentifikasi slot dengan latensi terendah yang perlu ditargetkan sebelum slot tersebut tiba. Data bergaya peta publik dan API RPC native berguna untuk visibilitas jaringan yang luas, tetapi tidak cukup presisi untuk pengaturan waktu eksekusi. Leader Slot API mengisi celah tersebut dengan granularitas yang dibutuhkan untuk keputusan routing dan trading.
Validators Solutions - Data jaringan Solana
Data jaringan Solana: Validators Solutions

Q. Bagaimana saya bisa mencapai trading zero-block (zero-slot)?

Untuk berhasil melakukan trading zero-block (zero-slot), diperlukan strategi yang lebih canggih seperti berikut:
  • Mengidentifikasi Zona Peluang: Validator Solana tersebar secara global, dan secara fisik tidak mungkin mencapai latensi optimal untuk setiap slot. Oleh karena itu, pantau jadwal pemimpin validator di region tempat infrastruktur Anda berada dan identifikasi zona peluang yang paling menguntungkan. Men-deploy infrastruktur di berbagai region juga dapat menguntungkan. Sebagai contoh, Frankfurt adalah region kunci karena kepadatan validatornya yang tinggi, sehingga validator di region ini lebih sering terpilih sebagai pemimpin dan peluang trading pun lebih besar.
    Gunakan ERPC Leader Slot API (getLeaderSlots) untuk melihat jadwal pemimpin yang akan datang, bobot stake untuk epoch saat ini, perkiraan data geolokasi validator, dan nilai ping referensi dengan presisi yang jauh lebih tinggi daripada sumber data bergaya peta publik atau API RPC native. Dengan begitu, Anda dapat memetakan zona peluang sebelum slot tiba dan mengeksekusi trade dengan latensi mendekati nol.
  • Menerapkan Node Dedicated: Jika Anda kesulitan bersaing, pertimbangkan untuk men-deploy node dedicated. Node bersama mengalami latensi karena lalu lintas dari pengguna lain, sehingga tidak direkomendasikan. Selain itu, menempatkan node dedicated Anda dalam jaringan yang sama dengan aplikasi Anda secara signifikan mengurangi latensi jaringan dan mengoptimalkan kinerja.

Q. Bisakah saya menggunakan endpoint tertentu?

Untuk mempertahankan lingkungan latensi rendah, sistem kami secara otomatis memilih node terdekat yang tersedia. Jika Anda ingin menggunakan endpoint tertentu, kami merekomendasikan menyewa server yang terletak paling dekat dengan endpoint tersebut.

Q. Saya mendapatkan error 401. Mengapa?

Untuk mempertahankan lingkungan latensi rendah, kami menerapkan pembatasan IP. Jika Anda tidak memiliki langganan atau IP Anda tidak terdaftar, Anda akan menerima error 401.
Mohon periksa kembali apakah IP terdaftar Anda cocok dengan IP akses Anda saat ini.

Q. Saya mendapatkan error 429. Mengapa?

Anda telah mencapai batas koneksi paket Anda.
Jika Anda menemui error ini, pertimbangkan untuk meningkatkan paket Anda. Jika Anda memerlukan lebih banyak koneksi daripada yang disediakan paket premium kami, node gRPC dedicated akan lebih cocok.

Q. Mengapa endpoint dedicated lebih cepat?

Endpoint bersama digunakan oleh banyak pelanggan yang berbagi sumber daya yang sama. Seiring bertambahnya lalu lintas, latensi cenderung meningkat. Sumber daya server memiliki batas fisik, dan jumlah pekerjaan yang dapat ditanganinya terbatas. Ketika terlalu banyak permintaan tiba pada saat yang sama, permintaan tersebut harus diproses secara berurutan sehingga waktu respons menjadi lebih lambat.
Meskipun kami mengambil berbagai langkah untuk mengoptimalkan kinerja bahkan pada endpoint bersama, dengan endpoint dedicated Anda adalah satu-satunya pengguna sumber daya tersebut. Artinya, Anda sama sekali tidak terpengaruh oleh pengguna lain, sehingga respons tetap stabil dan cepat secara konsisten.
Selain itu, endpoint dedicated menyediakan opsi komunikasi tanpa TLS, seperti HTTP. Dengan melewati handshake TLS (sekitar 20ms), komunikasi menjadi lebih cepat lagi dibandingkan HTTPS.

Q. Apakah harga saya akan dinaikkan setelah saya berlangganan?

Selama langganan Anda tetap aktif, harga yang Anda kunci saat mendaftar terus berlaku. Lingkungan yang sanggup menangani beban kerja real-time Solana langka di seluruh dunia, dan kami berencana menaikkan harga seiring meningkatnya permintaan hardware dan jaringan. Konfigurasi dengan spesifikasi lebih tinggi dan region dengan permintaan tinggi paling cepat terjual habis, sehingga mengunci harga saat ini adalah pilihan yang paling hemat biaya dalam jangka panjang.

Q. Saya ingin membayar dengan crypto

Pembayaran crypto tersedia dari ERPC Web Dashboard jika negara alamat penagihan terdaftar Anda termasuk negara anggota Uni Eropa. Jika semua kartu pembayaran yang terdaftar di akun Anda diterbitkan di luar Uni Eropa, pembayaran crypto tidak tersedia. Anda dapat menggunakan SOL, USDC, atau EURC untuk membeli ERPC Credits.
Gunakan ERPC Credits tersebut untuk mengaktifkan atau melanjutkan paket ERPC. Buka dashboard, pilih pembayaran crypto, kirim transfer dari wallet Anda, lalu dashboard akan memverifikasi transaksi dan menambahkan credits ke akun Anda.
Negara yang didukung: Austria, Belanda, Belgia, Bulgaria, Ceko, Denmark, Estonia, Finlandia, Hungaria, Irlandia, Italia, Jerman, Kroasia, Latvia, Lituania, Luksemburg, Malta, Polandia, Portugal, Prancis, Rumania, Siprus, Slovakia, Slovenia, Spanyol, Swedia, Yunani.
Untuk negara yang tidak ada dalam daftar, silakan bayar dengan kartu kredit.
ERPC Web Dashboard

Q. Bagaimana saya bisa mencapai latensi serendah mungkin?

Kami sangat merekomendasikan menggabungkan node gRPC dedicated dengan server Bare-Metal kami.
Keduanya berbagi jaringan yang sama, memungkinkan komunikasi pribadi tanpa jarak (zero-distance) tanpa melintasi internet. Pengaturan ini mencapai latensi yang sangat rendah, biasanya sekitar 0.1ms ping.
Silakan hubungi kami melalui ERPC Web Dashboard untuk detail lebih lanjut.
ERPC Web Dashboard
🔗 ERPC Web Dashboard

Q. Bagaimana latensinya?

Latensi bervariasi tergantung pada metode pengukuran dan lingkungan penggunaan spesifik Anda. Daripada berfokus pada nilai numerik yang tepat, sangat penting untuk memastikan bahwa latensi memenuhi persyaratan operasional Anda yang sebenarnya.
Kami menyediakan alat yang mudah digunakan dalam TypeScript dan Rust untuk mengukur latensi.

Q. Apakah RPC ini (gRPC, Shreds) lebih cepat daripada yang lain?

Kami merancang setiap tingkatan harga untuk kecepatan, dan kami senang jika hal itu diukur berdampingan dengan penyedia lain mana pun. Hasilnya dapat berbeda tergantung pada region, penggunaan endpoint bersama atau dedicated, protokol yang digunakan (WebSockets, gRPC, atau Shreds), dan bahasa pemrograman client Anda.
Jika Anda menemukan layanan kami lebih lambat, mohon beri tahu kami kondisi spesifik dan pesaing yang Anda bandingkan melalui ERPC Web Dashboard. Kami akan mengidentifikasi penyebabnya dan meningkatkan kecepatannya lebih lanjut.
ERPC Web Dashboard

Q. Paket mana yang menawarkan kinerja tercepat?

Secara umum, paket tier tertinggi kami memberikan kinerja tercepat berkat CPU yang unggul, kapasitas memori yang lebih tinggi, dan konfigurasi hardware yang tangguh.
Kami juga menawarkan solusi yang disesuaikan jika Anda memerlukan server yang lebih kuat lagi, tetapi paket standar kami dirancang untuk memberikan rasio harga terhadap kinerja yang optimal.
Kami yakin dapat memberikan kinerja kelas dunia di setiap tingkat harga. Jika Anda menemukan penyedia yang lebih cepat dalam kisaran harga yang sama, mohon beri tahu kami agar kami dapat menyelidiki dan membuat perbaikan.

Q. Saya mengalami latensi tinggi. Apa yang bisa saya lakukan?

Latensi sangat bergantung pada kedekatan Anda dengan endpoint. Kami merekomendasikan mengakses dari server yang dekat dengan endpoint yang disediakan. Koneksi tercepat dicapai dengan server Bare-Metal dan layanan VPS kami.

Q. Manakah yang tercepat: WebSockets, gRPC, atau Shreds?

Umpan balik dari pelanggan kami secara konsisten memeringkat kecepatan sebagai berikut:
Shreds > gRPC > WebSockets
Mohon bagikan pengalaman Anda jika Anda mengamati hasil yang berbeda.

Q. Latensi tidak seperti yang saya harapkan.

Kinerja bervariasi tergantung pada bahasa pemrograman yang digunakan. Secara umum, peringkat kecepatan bahasa:
Rust > Go > TypeScript (JavaScript) > Python
Untuk perbandingan rinci, lihat:
Perbandingan Kecepatan Bahasa Pemrograman
Untuk kinerja maksimum, kami sangat merekomendasikan menggunakan Rust.
SebelumnyaContoh kodeBerikutnyaSolana Shreds / gRPC / Quickstart