Die Rest-API von okex ist zu streng eingeschränkt und versucht, mit einer Dial-Websocket-Verbindung tiefgreifende Informationen zu erhalten. Da die Anzahl der gleichzeitigen Abonnements (etwa 80) sehr groß ist, ist es sehr zeitaufwendig, die Prozesslogik, die Bestellung und die Abfrage zu erledigen. Dies führt zu etwas größeren Ausführungsintervallen und zu viel Datenaufkommen der ws.read-Funktion, so dass die Lesezeit und die Tiefenwartung pro Leserrunde relativ lang sind und die Effizienz nicht hoch ist. Finden Sie heraus, ob es möglich ist, einen eigenen Prozess zu haben, der sich nur darum kümmert, die Websocket-Informationen zu durchlaufen, die Tiefe zu pflegen und die aktualisierten Tiefeninformationen über den lokalen Port an den Roboter weiterzugeben.
Die Erfinder quantifizieren - Kleine TräumeIch weiß nicht. Finden Sie heraus, ob es möglich ist, einen eigenen Prozess zu haben, der sich nur darum kümmert, die Websocket-Informationen zu durchlaufen, die Tiefe zu pflegen und die aktualisierten Tiefeninformationen über den lokalen Port an den Roboter weiterzugeben. Ich weiß nicht. Diese Notwendigkeit kann realisiert werden. Die Dial-Funktion ist in einem nicht blockierbaren Sofort-Rückkehr-Modus.
KirchillxyIch war auch mit diesem Bedürfnis konfrontiert, einen Plan für den Kauf und Verkauf mit Websocket zu erstellen, rest, ist das vernünftig?