Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wir sterben ohne Grund #38

Closed
Fabioni opened this issue Jan 12, 2021 · 4 comments
Closed

Wir sterben ohne Grund #38

Fabioni opened this issue Jan 12, 2021 · 4 comments

Comments

@Fabioni
Copy link

Fabioni commented Jan 12, 2021

Guten Abend,
mein Team ist sehr frustriert aufgrund von seltsamen Fehlern, welche bei der bereitgestellten online Plattform der Gi auftreten. Dies vermuten wir zumindest.

Es kommt seit gestern vermehrt vor, dass wir ohne Grund auf active: false gesetzt werden.
Alle angegebenen Zeiten sind in UTC. Ich schildere eine der besagten Situationen in Runde 137/138 eines Spiels welches um 2021-01-12_16:34:03 startete.

Die Deadline war: 2021-01-12 16:59:32
Daraufhin sendeten wir send {"action": "turn_left"}, was in dieser Situation offensichtlich eine möglicher Zug war, der nicht zum sterben führen konnte. Die Sendezeiten waren:

send at 2021-01-12 16:59:31.500592
send finish at 2021-01-12 16:59:31.500832

Wir haben also rechtzeitig die Nachricht abgesendet und das auch erfolgreich wie der send-finish Zeit zu entnehmen ist. Danach fragten wir einen neuen State an um

start recv() at 2021-01-12 16:59:31.500917

und bekamen diesen daraufhin auch zugeschickt um:

finish recv() at 2021-01-12 16:59:34.176797

Dieser neue State führte uns allerdings als "active":false und auch unsere Aktion turn_left wurde nicht umgesetzt. Die anderen Spieler wurden am Leben gelassen und haben sich auch bewegt.

Dies ist in den letzten Wochen nie vorgekommen und seit gestern geschieht es ständig. Den Zeitstempeln kann man entnehmen, dass das Problem nicht an uns liegt, oder sieht hier jemand was? Außerdem tritt das Problem ja auch nicht immer auf sondern nur sehr oft, von daher bin ich noch mehr überfragt.

Sieht jemand das Problem oder hat eine Idee?

Ich gehe davon aus, dass der Fehler bei der Gi liegt, da wir parallel zu diesem Problem auch ein enormer delay in der Abfrage der time_url feststellen mussten seit gestern, wofür es bereits ein anderes Issue gibt, welches nicht von mir angelegt wurde.

Vielen Dank an alle :-)

@Top-Ranger
Copy link
Collaborator

Hat sich das Problem mittlerweile wie #36 gelöst?

@Fabioni
Copy link
Author

Fabioni commented Jan 14, 2021

Wir haben das Spiel beobachtet und das Problem ist noch ein paar mal aufgetreten aber dann nicht mehr. Ich geh daher davon aus, dass das Problem noch besteht in eurer Architektur. Bei Tests habe ich immernoch feststellen können, dass die time_url manchmal sehr lange braucht zu antworten. Circa einmal die Stunde dauert sie länger als eine Sekunde zum Antworten.

@Top-Ranger
Copy link
Collaborator

Meine Vermutung ist, dass euer Spieler nicht rechtzeitig eine Antwort geschickt hat. Dabei müsst ihr unter anderem auch entsprechende Netzwerklatenzen mit einkalkulieren (die auch auf eurer Seite passieren können). Bitte beachtet auch, dass die Antwort zur Deadline beim Server angekommen sein muss (wie in der Aufgabenstellung angegeben). Solltet ihr also die Antwort sehr knapp abschicken und z.B. minimale Netzwerklatenzen auftreten, dann kann das genau euer Problem erklären.

@Fabioni
Copy link
Author

Fabioni commented Jan 16, 2021

Meine Vermutung ist, dass euer Spieler nicht rechtzeitig eine Antwort geschickt hat. Dabei müsst ihr unter anderem auch entsprechende Netzwerklatenzen mit einkalkulieren (die auch auf eurer Seite passieren können). Bitte beachtet auch, dass die Antwort zur Deadline beim Server angekommen sein muss (wie in der Aufgabenstellung angegeben). Solltet ihr also die Antwort sehr knapp abschicken und z.B. minimale Netzwerklatenzen auftreten, dann kann das genau euer Problem erklären.

wie meiner Frage zu entnehmen haben wir die Antwort rechtzeitig geschickt. "finish recv()" ist nach der Deadline passiert. Da TCP und blockierender Aufruf von send(), ist das also eindeutig angekommen am Server rechtzeitig.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants