Habe auf den Client oderDer-ID-Bereichs-Split zurückgeblickt: Jemand hatte vor ein paar Tagen ein paar UI-IDs im Vergleich zu Client-Maschinen-IDs angesprochen, aber ich wollte vor allem auf den Aspekt der Latenz eingehen – und nicht nur auf die Seite der Kollisionsvermeidung, die bereits coveRed ist.
Die zwei Bereiche [0, 2^63-1] für von der UI generierte Orders und [2^63, 2^64-1] für von der Client-Maschine generierte Orders existieren primär, um Kollisionen zu verhindern – das ist die dokumentierte Begründung. Aber ich möchte in Frage stellen, ob dieser Split auch irgendwelche Latenz-Auswirkungen hat, speziell für automatisierte Handelssysteme.
Hmm, wenn die GRVTs-Matching-Engine oder das Gateway jemals unterscheiden muss, ob ein Flow von der UI oder von der API stammt, aus irgendeinem operativen Grund (z. B. Rate Limiting, Priorisierung, Monitoring), dann würde es – indem diese Unterscheidung direkt im ID-Bereich kodiert ist – ermöglichen, dass es ohne zusätzliche Metadaten-Lookups passiert; allein der Bereich sagt dir die Herkunft.
Das ist Spekulation meinerseits; das Whitepaper dokumentiert nur die Kollisionsvermeidung als den genannten Grund. Aber wenn das stimmt, würde es bedeuten, dass der ID-Bereichs-Split still und heimlich einen doppelten Zweck erfüllt: Kollisionen verhindern und der GRVT gleichzeitig ein kostenloses Signal mit Nullkosten darüber geben, ob die Order von einer UI oder aus einer anderen Quelle stammt.
Habe aber noch keine Bestätigung, dass dieser Latenz- oder Herkunftserkennungs-Aspekt real ist – und nicht nur ein zufälliger Nebeneffekt einer Designentscheidung, die rein aus Gründen der Kollisionsvermeidung getroffen wurde.
@grvt_io #grvt $LAB $VELVET $EVAA
Die zwei Bereiche [0, 2^63-1] für von der UI generierte Orders und [2^63, 2^64-1] für von der Client-Maschine generierte Orders existieren primär, um Kollisionen zu verhindern – das ist die dokumentierte Begründung. Aber ich möchte in Frage stellen, ob dieser Split auch irgendwelche Latenz-Auswirkungen hat, speziell für automatisierte Handelssysteme.
Hmm, wenn die GRVTs-Matching-Engine oder das Gateway jemals unterscheiden muss, ob ein Flow von der UI oder von der API stammt, aus irgendeinem operativen Grund (z. B. Rate Limiting, Priorisierung, Monitoring), dann würde es – indem diese Unterscheidung direkt im ID-Bereich kodiert ist – ermöglichen, dass es ohne zusätzliche Metadaten-Lookups passiert; allein der Bereich sagt dir die Herkunft.
Das ist Spekulation meinerseits; das Whitepaper dokumentiert nur die Kollisionsvermeidung als den genannten Grund. Aber wenn das stimmt, würde es bedeuten, dass der ID-Bereichs-Split still und heimlich einen doppelten Zweck erfüllt: Kollisionen verhindern und der GRVT gleichzeitig ein kostenloses Signal mit Nullkosten darüber geben, ob die Order von einer UI oder aus einer anderen Quelle stammt.
Habe aber noch keine Bestätigung, dass dieser Latenz- oder Herkunftserkennungs-Aspekt real ist – und nicht nur ein zufälliger Nebeneffekt einer Designentscheidung, die rein aus Gründen der Kollisionsvermeidung getroffen wurde.
@grvt_io #grvt $LAB $VELVET $EVAA