Skip to main content
Die Zustellung erfolgt höchstens einmal — es gibt keine Wiederholung. Was während der Trennung bestätigt wurde, wird nicht erneut gesendet, daher muss ein Produktionsclient die Lücke erkennen und entscheiden, ob er sie auffüllen möchte. Das Signal dafür ist context.slot: es begrenzt das Fenster, das Sie während einer Unterbrechung verpasst haben. Dieser Leitfaden erklärt, warum Verbindungen geschlossen werden, wie man sauber erneut verbindet und wie man es nutzt.

Warum Verbindungen geschlossen werden

Jede Schließung hat einen WebSocket-Schließcode, der erklärt, was passiert ist und was als nächstes zu tun ist: Der Server sendet alle 15 Sekunden Pings, sodass eine gesunde, aber ruhige Verbindung immer noch Verkehr trägt. Wenn Sie mehr als eine Minute lang überhaupt nichts sehen — keine Benachrichtigung, kein Ping — gehen Sie davon aus, dass die Verbindung tot ist und stellen Sie die Verbindung wieder her, anstatt darauf zu warten, dass der Socket es Ihnen sagt.

Halten Sie die Verbindung am Leben

Wenn Ihr Filter so eng ist, dass er legitim 10 Minuten ohne Übereinstimmung bleiben kann, senden Sie eine explizite JSON-RPC ping in einem Intervall, das kürzer ist:
Es gibt den aktuellen Slot zurück und zählt, noch wichtiger, als Client-Nachricht für den Leerlauf-Timer. Ein Bibliotheksebene-WebSocket-Ping-Frame tut dies nicht.

Erneut verbinden und die Lücke erkennen

1

Mit Backoff erneut verbinden

Bei jeder Schließung — erwartet oder unerwartet — erneut verbinden mit exponentiellem Backoff. Abonnement-IDs überleben eine erneute Verbindung nicht, daher senden Sie parsedTransactionSubscribe für jeden Filter, den Sie geöffnet hatten, erneut.
2

Verfolgen Sie context.slot über Unterbrechungen hinweg

Behalten Sie den letzten context.slot, den Sie vor der Unterbrechung gesehen haben. Die Lücke zwischen diesem Slot und dem ersten Slot, den Sie nach der erneuten Verbindung sehen, ist genau das Fenster, das Sie verpasst haben — nichts mehr, nichts weniger.
3

Füllen Sie auf, wenn Sie müssen

Wenn Ihre Anwendung die Lücke nicht tolerieren kann, füllen Sie dieses Slot-Fenster von RPC auf: Verwenden Sie getSignaturesForAddress, um Transaktionen im Bereich aufzulisten, und dann getTransaction, um jede einzelne abzurufen. Dies ist ein manueller Abgleichsschritt — geparste Streams selbst spielen nicht erneut ab.
context.slot ist das, was eine erneute Verbindung überlebt: Verfolgen Sie den höchsten Slot, den Sie vollständig vor der Unterbrechung verarbeitet haben, und behandeln Sie alles danach als Auffüllfenster.

Umgang mit JSON-RPC-Fehlern

Anfragen, die fehlschlagen, geben einen JSON-RPC-Fehler anstelle eines Ergebnisses zurück, sodass Sie auf error.code verzweigen können: -32602 und -32000 bedeuten, dass die Anfrage selbst falsch ist — korrigieren Sie den Filter, versuchen Sie nicht, ihn so erneut zu senden. -32001 und -32002 sind vorübergehend; versuchen Sie es erneut mit dem gleichen Backoff, den Sie für erneute Verbindungen verwenden.

Nächste Schritte

Schnellstart

Vollständige Protokollreferenz: Methoden, Filterfelder, Grenzwerte.

Verfolgen Sie Jupiter Swaps

Erstellen Sie einen Filter, auf den diese Verbindung abonnieren kann.