FEATURE Erfolgreiche Targetübermittlung in Drift-App kommunizieren

[Jash]

Szenario
Jedes erfolgreich übermittelte Target (mit positiver Server-Rückantwort {status: true}) erzeugt einen kurzen Ton und/oder ein kurzes Vibrieren, welches sich von der internen erfolgreichen Target-Kommunikation wahrnehmbar unterschiedet bzw. diese auch gänzlich ersetzt (die erfolgreiche Serverübermittlung hat in diesem Fall Priorität). Dies wird zwar leicht zeitversetzt durch die Server-Antwort-Zeit zum eigentlichen Zeitpunkt der Erkennung dann kommuniziert, aber man kann sich zumindest sicher sein, dass der Server das Target-Request verarbeitet hat und bekommt auch ein Gefühl wie "schnell" der Server gerade läuft. Auch könnten so abgelehnte Targets (z.B. durch Timeout) mit dem Fahrer kommutiert werden, ohne auf das Display schauen zu müssen.

Diese Server-Target-Kommunikation sollte optional aktiviert bzw. deaktiviert werden können.

Bearbeitet 11. Juli 2022 von Jash

[Zockermichi125]

Sehr gute Idee. Find ich auch dass das implementiert werden soll. Ich würde es aber nicht mit ne JSON Payload machen sonder der Server soll einfach mit dem StatusCode 200 OK antworten. Sollte er nicht mit OK antworten so soll die CAPI an bestimmte Anzahl an Versuchen erneut versuchen das Target zu übermitteln.

[Decrayer]

Habs mal mit aufgenommen, ich seh das aber mit gemischten Gefühlen: Die Driftapi ist mit der Philosophie entstanden, dass die Übermittlung der Events nicht super schnell erfolgen muss, sondern dann, wenn Zeit ist. Oberste Priorität der App hat ja immer die Simulation und die Übermittlung an den Racer, danach die UI auf dem Handy und erst wenn dann noch Zeit in der Game Loop ist, ein kurzer call an die Drift-API. D.h. eine Zeitnahe Übertragung an die API ist bisher nicht wirklich notwendig und eine zeitnahe Antwort erst recht nicht, tatsächlich ist es der Drift-App bei den meisten Events schnuppe und das ist auch gut so, denn dadurch blockiert sie nicht und muss auch keinen späteren Interrupt machen oder in der game loop nach eingegangenen Antworten fragen. Ein solches Feature einzubauen bedeutet daher, so einige Prinzipien umzuschmeissen und bei der Implementierung in die Game-Loop einzugreifen. Beim /ping Befehl ist das weniger kritisch, weil da nicht viel Echtzeitmässig passiert, in der Gameloop sieht das schon anders aus.

Ich neh'm den Vorschlag mal auf, aber ganz ehrlich sehe ich nicht, dass das eine hohe Priorität haben wird, weil man für so einen Eingriff in den zeitkritischen Teil der App etwas mehr "Benefit" braucht als nur nen Ton abzuspielen. Man könnte das ganze ja auch Serverseitig lösen und dort einen Ton über die Webseite abspielen sobald ein Target erkannt wurde, in verschiedenen Tonhöhen für die unterschiedlichen Spieler.

[Zockermichi125]

Es geht hier nicht primär um die schnelle Übermittelung sonder um die gesicherte Übermittelung an der Daten an den Consumer der CAPI. Deswegen hab ich geschrieben sollte die CAPI auch mehrmals probieren die Requests zu feuern um bestmöglichst zu gewährleisten dass die Datenübertragung funktioniert/geklappt hat.  Das Thema "Rückantworten" wird auch sehr wichtig und wie ich empfinde ist auch momentan eines der wichtigsten Themen.

[Decrayer]

Bitte melde dich an um den Link zu sehen.

 200 OK reicht dafür ja aus, aber die zuverlässige Übermittlung der Information (unter "Sicher" verstehe ich etwas anderes) sollte alleine schon im Layer darunter durch TCP gewährleistet sein. Ein manuelles überprüfen und neu Versenden würde quasi die Funktion von TCP nachimplementieren.

[Zockermichi125]

Bitte melde dich an um den Link zu sehen.

Da verstehst die Idee a bissl falsch. Ich gebe dir mal a Beispiel.

Die CAPI schießt ein Event zur API. Die API versucht das Event zu verarbeiten. Es läuft aber in einen 500er weil er keine Connection zum DB Server herstellen weil dieser eine Downtime hat. => Event für immer verloren
Ihr müsst da einfach ne Retry Policy einbauen damit er so z.B. 3 Mal probiert den Call zu feuern und wenn ne 500er kommt nochmal probieren.

[Decrayer]

Bitte melde dich an um den Link zu sehen.

Ich hab das Gefühl, dass so eine Funktion eher eine separate Idee darstellt, vielleicht besser nen neuen Feature Request dafür eröffnen?

[Zockermichi125]

Bitte melde dich an um den Link zu sehen.

Ja wir können gerne ne extra Feature Request erstellen wenn du möchtest 🙂 Sehr gute Idee 🙂