Was es braucht, eine Plattform mit etwas anderem zu verbinden

Zwei Formen von Schnittstelle, für Verschiedenes gebraucht

Die Programmierschnittstelle eines Brokers kommt in der Regel in zwei Formen. Die eine beantwortet jedes Mal eine Frage, wenn sie gestellt wird, und sagt dazwischen nichts: eine Anfrage geht raus, eine Antwort kommt zurück, und bis zur nächsten Anfrage ist nichts weiter bekannt. Die andere hält eine Verbindung offen und schickt Aktualisierungen, sobald sie anfallen, sodass Informationen eintreffen, ohne erbeten worden zu sein.

Broker bieten üblicherweise beide an, und sie sind keine Alternativen in dem Sinn, den eine Optionsliste nahelegt. Sie beantworten verschiedene Fragen. Alles, was eine bestimmte Antwort über eine bestimmte Sache in einem bestimmten Moment braucht — der Zustand dieser Order, was das Konto gerade hält —, ist eine Frage, und Fragen gehören zur ersten Form. Alles, was Bescheid wissen muss, während sich etwas ändert, gehört zur zweiten.

Wiederholtes Abfragen hat einen Boden, unter den es nicht kommt

Einen Kurs wiederholt abzufragen statt ihn zu abonnieren ergibt ein Bild, das nie frischer ist als der Abstand zwischen den Anfragen. Den Abstand zu halbieren halbiert die Veraltung und verdoppelt die Zahl der Anfragen, und es gibt einen Punkt, ab dem der Broker diese Zahl nicht mehr annimmt. Es gibt also einen Boden darunter, wie aktuell ein so gewonnenes Bild sein kann, und wo dieser Boden liegt, entscheidet jemand anderes.

Das wiegt schwerer, als es klingt, denn Veraltung wandert weiter. Jede Entscheidung, jede Anzeige, jeder Vergleich auf Basis eines so geholten Werts erbt dessen Alter, ohne ein Etikett mitzuführen, das es sagt. Ein System, das abfragt und dann handelt, handelt auf einer Zahl, deren Alter es meist nirgends festgehalten hat.

Ein Limit sind meistens mehrere Limits

Ein Anfragelimit ist eine Obergrenze dafür, wie viele Anfragen ein Konto innerhalb eines Zeitraums senden darf, und es ist selten eine einzige Zahl. Verschiedene Endpunkte werden getrennt gezählt, und das Kontingent zum Lesen von Kursen ist in der Regel nicht das Kontingent zum Senden von Orders. Ein System, das am großzügigen Limit bemessen wurde, kann am strengen abgelehnt werden, und zwar im unpassendsten Moment, weil sich Orderverkehr genau dann ballt, wenn sich Kursverkehr ballt.

Welche Limits gelten und wie sie gezählt werden, dokumentiert der Broker; durch Ausprobieren findet man es nicht heraus. Die Wand dadurch zu finden, dass man hineinläuft, heißt Ablehnungen auszugeben, um zu erfahren, wo sie steht — auf einem echten Konto und in dem Moment, in dem das Hineinlaufen gerade stattfindet.

Der teure Umgang mit einer Ablehnung

Sofort erneut zu versuchen verschlimmert ein Anfragelimit, denn die Wiederholungen werden mitgezählt, und ein System, das auf Drosselung mit mehr Nachdruck reagiert, drosselt sich selbst weiter. Zurückzunehmen statt zu drücken ist hier das gesamte richtige Verhalten, und es ist gerade deshalb unintuitiv, weil die meisten anderen Fehlerarten Hartnäckigkeit belohnen.

Das ernstere Problem ist, dass eine Ablehnung nicht immer von anderen Fehlern zu unterscheiden ist. Eine Anfrage, die auf der Clientseite in eine Zeitüberschreitung lief, kann trotzdem empfangen und ausgeführt worden sein, und keine Antwort als keine Order zu behandeln ist der Weg, auf dem ein System dieselbe Order zweimal sendet. Alles, was über eine Schnittstelle handelt, muss erst feststellen, was tatsächlich geschehen ist — indem es das Konto zurückliest —, bevor es erneut handelt. Das ist eine andere Operation als ein erneuter Versuch, und sie ist die, die zuerst kommen muss.

Ein Datenstrom, der offen und still ist

Ein Datenstrom nimmt den Boden des Abfragens weg und bringt im Tausch seine eigene Arbeit mit. Verbindungen brechen ab und müssen neu aufgebaut werden. Aktualisierungen, die währenddessen verpasst wurden, müssen von irgendwoher nachgeholt werden, was meist heißt, die andere Art von Schnittstelle nach dem aktuellen Zustand zu fragen, statt anzunehmen, die Lücke habe nichts enthalten.

Der schwierige Fehler ist keiner von beiden. Es ist eine Verbindung, die noch offen ist und nichts mehr liefert, und die genau wie ein ruhiger Markt aussieht — denn ein ruhiger Markt liefert ebenfalls nichts. Den Inhalt des Eingetroffenen zu prüfen trennt die beiden nicht, da in beiden Fällen nichts eingetroffen ist. Was sie trennt, ist die Zeit: das Alter der letzten Nachricht und nicht das, was darin stand. Software, die einen Strom verarbeitet, braucht etwas, das von selbst veraltet und das auch sagt, sonst liest sie eine tote Verbindung so lange als ruhige Bedingungen, wie der Zustand anhält.

Ein an eine Adresse geschickter Alarm ist einseitig

Ein Alarm an eine Webadresse ist die Plattform, die eine Nachricht an eine vom Leser angegebene Adresse schickt, wenn eine an einem Chart definierte Bedingung erfüllt ist — statt sie auf dem Bildschirm zu zeigen oder zusätzlich dazu. Das ist die übliche Brücke zwischen Analyse an einem Ort und Handlung an einem anderen, und der Reiz liegt auf der Hand: eine am Chart ausgedrückte Bedingung wird zur Eingabe für andere Software.

Zu verstehen lohnt sich, dass es Senden und Vergessen ist. Der Sender erfährt in der Regel, ob die Nachricht angenommen wurde, und überhaupt nichts darüber, was mit ihr geschehen ist. Zustellungen können spät, in falscher Reihenfolge oder mehrfach eintreffen. Eine fehlgeschlagene Nachricht wird vielleicht wiederholt und vielleicht nicht, und diese Regel gehört dem Sender und nicht dem Leser. Nichts davon macht den Mechanismus schlecht. Es macht ihn zu einem Mechanismus, dessen Zusagen schwächer sind, als sie aussehen, und die stärkeren anzunehmen ist der Weg, einen stillen Fehler von Anfang an einzubauen.

Die Adresse ist kein Zugangsnachweis

Ein Empfänger hat keine Möglichkeit festzustellen, wer ihm eine Anfrage geschickt hat, solange die Anfrage es nicht beweist. Die Adresse ist damit das Einzige, was zwischen dem Alarm und jedem anderen steht, der die Adresse erfährt, und Adressen entkommen auf ganz gewöhnlichen Wegen: in eine Supportanfrage eingefügt, in ein geteiltes Dokument kopiert, in einem Bildschirmfoto sichtbar gelassen.

Ein Empfänger, der auf Eintreffendes hin handelt, trägt deshalb zwei Pflichten, und beide folgen aus allem Obigen. Er muss die Nachricht authentifizieren, statt der Tatsache ihres Eintreffens zu trauen, und er muss es aushalten, dieselbe Nachricht zweimal zu sehen, ohne die Sache zweimal zu tun. Keine der beiden ist interessante Arbeit, beide lassen sich leicht aufschieben, solange ein Aufbau noch getestet wird, und zusammen sind sie der Unterschied zwischen einer Brücke und einem Loch.