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-RPCping in einem Intervall, das kürzer ist:
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 auferror.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.