Aufrechterhaltung einer konsistenten Markttiefe mit der Mt.Gox-API

Ich versuche, ein Programm zu schreiben, das die Mt.Gox-API verwendet, um eine aktuelle, konsistente Ansicht ihrer Markttiefe zu erhalten. Meine derzeitige Vorgehensweise ist wie folgt:

  • Verbinden Sie WebSocket und abonnieren Sie Tiefenaktualisierungen
  • Warten Sie 1 Minute und sammeln Sie Updates
  • Fordern Sie vollständige Markttiefendaten über http://data.mtgox.com/api/1/BTCUSD/depth/full an
  • Zusammenführen der gesammelten Updates in die Marktdaten nach Zeitstempel (jüngere Gewinne)
  • Fahren Sie fort, alle zukünftigen Updates in Daten zusammenzuführen

Nachdem ich eine Weile damit herumgespielt hatte, bemerkte ich, dass der Download der Daten in voller Tiefe nicht immer mit den Daten übereinstimmt, die durch Updates generiert wurden. Aus diesem Grund habe ich die 1-Minuten-Verzögerung hinzugefügt, weil ich dachte, dass der Mt.Gox-Server die Daten mit voller Tiefe möglicherweise nur regelmäßig aktualisiert, aber nicht im laufenden Betrieb generiert.

Aber selbst mit diesem Protokoll sehe ich, wenn ich das Programm zweimal parallel laufen lasse, in beiden Fällen unterschiedliche Daten.

Irgendeine Idee, was ich falsch machen könnte?

Antworten (1)

Meiner Erfahrung nach führt das Anfordern der vollen Markttiefe von MtGox oft zu völlig falschen Informationen. Um damit umzugehen, habe ich auf die Konstruktion meiner eigenen zurückgegriffen, ähnlich wie Sie es oben beschrieben haben.

Ich schaue mir mit der Websocket-API alle eingehenden depthEreignisse an. Ich behalte dann zwei geordnete Arrays von Bids und Asks. Bei Tiefenereignissen, wenn das Volumen positiv ist, füge ich die Reihenfolge basierend auf der type_strEigenschaft dem jeweiligen Array hinzu. Wenn das Volumen negativ ist , entferne ich das Objekt aus dem Array.

Stellen Sie sicher, dass Sie Objekte mit demselben Preis, aber unterschiedlichem Volumen kombinieren. Ebenso beim Entfernen von Objekten, wenn das negative Volumen geringer ist als das Volumen des Objekts mit denselben Preisen, dann nur vom Volumen abziehen, anstatt es zu entfernen. So wird es auf dem Server von MtGox gemacht und es wird zu Fehlern führen, wenn es anders gemacht wird.

Nachdem dies eine Weile laufen gelassen wurde, wenn auch nicht tief, ist das Orderbuch ziemlich genau und repräsentativ für das, was das MtGox-Orderbuch sein sollte.

Hi! Ich habe auch versucht, mein eigenes Orderbuch zu verwalten und habe festgestellt, dass es nach einiger Zeit Einträge ansammelt, die längst entfernt werden sollten. Aber ich habe bisher nur das Feld "Gesamtvolumen" der Ereignisse "Tiefe" verwendet. Erscheinen die in den „Handels“-Ereignissen enthaltenen Informationen tatsächlich nicht als „Tiefen“-Ereignisse? Haben Sie auch festgestellt, dass die Informationen zum inkrementellen Volumen (positiv vs. negativ) genauer sind als die Verwendung des Felds "Gesamtvolumen"? Vielen Dank!
Daher habe ich die Größe geändert, sodass alle Handelsereignisse ein entsprechendes Tiefenereignis mit negativem Volumen haben. Wenn Sie also nur Tiefenereignisse verwenden, können Sie ein Auftragsbuch erstellen, indem Sie alle Tiefenobjekte mit positivem Volumen hinzufügen und Objekte mit negativem Volumen entfernen. Um sicherzustellen, dass sie gleich sind, passe ich die Felder price_intund an, bevor ich das Objekt entferne. amount_intIch benutze total volumeüberhaupt nicht und habe festgestellt, dass dies ganz gut funktioniert.
Hmmm ... Ich habe auch price_int verwendet, um die Einträge abzugleichen ... lassen Sie mich versuchen, amount_int anstelle von total volume zu verwenden, um zu sehen, ob das zuverlässiger ist ... Haben Sie jemals bemerkt, dass Tiefenereignisse "außerhalb der Reihenfolge" ankommen, dh Sie erhalten ein Ereignis mit einem "Jetzt"-Zeitstempel, der vor dem Zeitstempel eines zuvor empfangenen Ereignisses liegt?
Nein, aber ich werde in Zukunft darauf achten. Stellen Sie außerdem sicher, dass Sie den absoluten Wert der negativen Volumina nehmen, bevor Sie sie mit bestehenden Aufträgen vergleichen.