J o: Nachtrag: Zeitdifferenz

Beitrag lesen

Hey,

ich verstehe dein Thema so:

Du hast also einen Client-Request. Der startet auf dem Server eine Aktivität. Und diese Aktivität hat eine geschätzte Laufzeit. Der Client soll sich erst nach Ablauf dieser geschätzten Laufzeit wieder melden. Dann gib doch vom Server einfach diese geschätzte Laufzeit zurück. Der Client setzt basierend darauf mit setTimeout(handler, estimatedTime) einen Timeout, nach dessen Ablauf das Ergebnis geholt wird.

Naja die Funktion die prüft ob die Endzeit erreicht ist läuft auf dem Client unabhängig davon alle 25ms einmal durch.

Welche Latenz hast Du bei Pings zu deinem Server? 100ms? Das wäre schon viel. Dein Client holt also mit maximal 100ms Verspätung die Antwort. Ist das tolerierbar? Oder programmierst Du unter Realtime-Bedingungen (wobei JavaScript dann nicht unbedingt die beste Plattform ist).

Ich versuche wenigstens so nah an Realtime heranzukommen wie ich es eben schaffe.

Angenommen, der Client meldet sich zu früh. Kannst Du am Server ermitteln, wie die vermutete Restlaufzeit ist? Wenn ja, kannst Du dem Client "hab noch xxx Sekunden Geduld" zurückgeben und der setzt sich das dann wieder als Wartezeit.

Ja, die Restzeit am Server ist kein Problem. Darauf könnte es vielleicht hinauslaufen. Also das der Client mitteilt, bei mir ist sekunde x erreicht und der Server wartet mit der Verarbeitung bis Sekunde x auch beim Server erreicht ist.

Achso - Websockets. Wäre das eine Alternative? Der Client wartet GAR NICHT. Er bekommt nur vom Server per Websocket die Antwort zugeschickt, sobald sie fertig ist.

Läuft alles schon mit einem Websocket mit Node.js und socket.io. Mein Server weiß aber gar nicht wann die Endzeit erreicht ist, der schaut nur in der Datenbank nach und vergleicht mit seiner Zeit. Und darauf hin wird eben entsprechend geändert/bearbeitet.

Gruß
Jo