| neue Message hinzufügen |

Bug-Fix / Neue Version ultimate 2018-12-27 12:20:07
Es gibt eine neue Bug-Fix Version des KaroMUSKELs im Wiki

Der Fix war nötig, weil Didi etwas an der newGame.php geändert hat und deshalt Karten mit Namen "(unbekannt)" (früher einfach nur ein leerer Name) nicht mehr geladen wurden.

Danke @Sayri für den Hinweis auf den Bug!null

Karaser 2017-08-30 18:32:42
Das Austeigen mit dem Muskel geht zumindest auch mit der neuen Version nicht.

Und wie hat sich der Fehler (mit den Umlauten) manifestiert? kili 2017-08-21 23:05:38
Zur 2.6er steht im Wiki ja " im Umlaut-Encoding der Spielerstellungs-Requests korrigiert".

Mag ja sein, dass da ein Fehler im Encoding war, aber wie kann so ein Fehler zu Amok-Spielerstellungen, wie wir sie in der Vergangenheit gesehen haben, fuehren? Die Spiele *wurden* ja erstellt, nur halt viel zu viele und in viel zu kurzer Zeit.

Ich meine, ist das bloss Spekulation, dass es mit dem Encoding zusammenhing, oder gibt es brauchbare Hinweise?

Wenn's Hinweise gibt, welche sind das dann?

Wo liegt der eigentliche Bug? Ist was an der Spielerstellung bei karopapier.de kaputt? Wenn ja, wie aeussert sich das?

-- kili

Nein Karaser 2017-08-21 21:47:27
Ich dachte dass sich die Aussage auf den Bug mit dem Spiele erstellen bezieht. Das mit dem Aussteigen funktioniert bei mir immer noch nicht...

Bug-Fix / Neue Version 2.6 ultimate 2017-08-20 20:07:32
Es gibt eine neue Version 2.6 im Wiki zum Download.

Ich bin über jedes Feedback dankbar, ob der Bug nun tatsächlich behoben ist...

@Karaser: Dem Chat entnehme ich, dass das Problem sich selbst gelöst hat?!

So nebenbei... Karaser 2017-08-14 18:24:06
...wäre es super, wenn du bei deiner nächsten Version das Aussteigen fixen könntest, das geht nämlich derzeit nicht. Er tut so als ob er was machen würde, zählt auch im Terminal runter, aber wirklich aussteigen macht er nicht...

ultimate 2017-08-10 10:12:47
Soweit ich weiß benutzen App und sly.wtf die KaroAPI, der KaroMUSKEL jedoch nicht. Das liegt in erster Linie daran, dass der KaroMUSKEL älter ist als die API (zumindest älter als die Erstell-Funktion der API).

Ursprünglich hatte ich Mal vor eine komplett neue Version 3 (weiterhin in Java) unter Verwendung der API und natürlich mit neuen Funktionen zu bauen, bin dann aber davon abgekommen und hatte mich entschlossen das ganze dann doch lieber als auch Mobile-taugliche Version 4 in HTML/JavaScript umzusetzen. (Das war sogar noch lange bevor es als.wtf gab). Seitdem habe ich so eine KaroMUSKEL-Baustelle vor mir und komme aufgrund zu vieler Projekte einfach nicht dazu daran weiter zu basteln... Mit dieser Version 4 hätte ich dann auch einen Export von der Java-Version und Import in die neue Version geplant - aber der steht mangels Zeit leider auch noch nicht... (Siehe auch http://www.karopapier.de/showthread.php?thread=968&forumid=1 )

Ich hatte auch Sly schon mal angeboten, dass man den KaroMUSKEL zu einem Gemeinschaftsprojekt machen könnte. Wer entsprechende Kenntnisse und Interesse hat sich daran zu beteiligen, kann gerne auf mich zukommen...

Vergleich mit der App und Sly.wtf MasterLex515 2017-08-10 06:48:34
auch in der Vergangenheit scheint nur der MUSKEL probleme zu machen bei der Spielerstellung?!

Andere Tools wie die Erstellung über die App und bei sly.wtf scheinen das problem nicht zu verursachen.

# kann man die prozesse der spielerstellung vergleichen und beim muskel anpassen? Spiele werden dann vom MUSKEL so erstellt wie von der App oder sly.wtf.  irgendetwas müsste es dort ja geben, dass spiele nicht doppelt erstellt werden.

# man könnte zukünftig beim muskel etwas von sly.wtf übernehmen: wenn ein spiel erstellt wurde, wird in die spielliste statt "erstell" die GID rein geschrieben.
Das wäre für die Ligaorganisation hilfreich. die Serie kann ja gespeichert werden und man kann so recht einfach die GIDs wiederfinden/zuordnen.

# könnte zukünftig der MUSKEL mit sly.wtf "verknüpft" wereden?
der Muskel könnte die Planung, Berechnungen, Organisation etc. übernehmen. Die entstandene Spielliste wird gespeichert und kann bei sly.wtf geladen werden. Hier wird dann nur noch ausgewählt, ob die komplette spielliste erstellt wird oder nur einzelne ausgewählte spiele. offene spiele können durch das laden der liste auch später erstellt werden.
im Prinzip genau wie beim MUSKEL, nur dass der "kritische" Spielerstellungsteil auf eine wahrscheinlich sicherere Plattform übertragen wird.

Nach aktuellem Stand würde ich ungern auf den MUSKEL komplett verzichten wollen, da es hier viele nützliche Funktionen und Einstellungen gibt wie sonst nirgends.

Theorie 2.0 ultimate 2017-08-08 21:51:15
Ich habe eine neue wilde Theorie, woran es liegen könnte.
Um diese zu überprüfen, würde ich gerne die Problem Spiele vergleichen, ob sie etwas gemeinsam haben und falls ja, was?

Kann mir jemand dafür eine Liste aller GIDs zu mehrfach erstellten Spielen aus der Datenbank raussuchen? (Eine Suche nach doppelten Spielbanken sollte für den Anfang reichen, auch wenn da natürlich noch Nicht-KaroMUSKEL-Spiele dabei sind.)

Ich werde die Theorie so oder so mal mit Logging & Debugging überprüfen, aber die Liste wäre schon mal eine Hilfe...

Dabke & Grüße

Logging einbauen, nicht auf API umstellen kili 2017-08-08 21:38:05
ultimate, bevor Du da jetzt auf die API umstellst oder sonst was schraubst, bau bitte Logging ein. Mit irgendeinem (threadsicheren) Logging-Framework.

Geloggt werden sollte vor jedem rausgehenden Request, welches Spiel der MUSKEL gerade zu erstellen glaubt, was er als Antwort vom Karoserver zurueckbekommt bzw., wenn er gar nichts zurueckbekommt (Timeout oder Exception) eben dieses Ergebnis (Stracktrace bei Exceptions ist ja gar nicht mal noetig, glaube ich). Alles mit Datum und Uhrzeit.

Wie man das vernuenftig hinbekommt, so dass es sowohl unter Unix als auch Windows funktioniert und der Benutzer anschliessend auch ans Logfile bekommt, weiss ich nicht, das ueberlasse ich Dir.

Aber *ohne* irgendwelches Logging ist und bleibt hier *alles* in wildes Rumgestochere im Dunkeln.

Vorschlag ... MasterLex515 2017-08-08 20:09:42
Ich bin zwar kein Programmierer wie ihr, habe aber folgende Idee :
-man könnte die Anzahl der zu erstellenden spiele mit der Anzahl der erstellten vergleichen und bei erreichen der entsprechenden Anzahl den Vorgang abbrechen falls noch aktiv.
-Es wird nur ein Spiel (auch nur einmal erstellt). Erst wenn das erfolgreich war wird das nächste Spiel erstellt.
-sodass sich der Muskel selbstkontrolliert und auch stoppen kann.
... Ich weiß dass es einfach gesagt ist als programmiert. Vielleicht helfen meine Gedanken

API ultimate 2017-08-08 19:40:00
... ich bezweifel, dass es was hilft die API zu nutzen - der KaroServer braucht ja vermutlich trotzdem genauso lange für die Spielerstellung...
Einen Versuch ist aber vermutlich wert. Ich schaue mal, ob ich das die Tage mal einbauen kann...

Daten rund um den muskel MasterLex515 2017-08-08 19:26:03
Hier mal meine Daten:
Betriebssystem Windows 10 64bit
Java Version 8.0
Muskel 2.5 (sollte nach den Angaben die aktuellste Version sein)

Karobot eisbaer04 2017-08-08 18:57:46
Solltest du vielleicht tun

Das ist nur die Ausgabe von meinem Karobot

ultimate 2017-08-08 18:19:19
Was heißt denn dieses "No Data. Load from API"? Ich benutze die API gar nicht...

mal wieder eisbaer04 2017-08-08 13:54:59
Heute zwischen 12 und 13:30 warf karopapier.de nur "Bad Gateways". Schuld scheint mal wieder der KaroMUSKEL gewesen zu sein...


GID 101588: No Data. Load from API.  2017-08-08 11:51:56 Robert l?sst den MUSKEL spielen Nr. 2 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101589: No Data. Load from API.  2017-08-08 11:57:57 Robert l?sst den MUSKEL spielen Nr. 3 mit Sly, cachito, mAvErICk, Robert und MasterLex515
GID 101590: No Data. Load from API.  2017-08-08 12:03:57 Robert l?sst den MUSKEL spielen Nr. 4 mit cachito, mAvErICk, Robert, Sly und MasterLex515
GID 101591: No Data. Load from API.  2017-08-08 12:09:57 Robert l?sst den MUSKEL spielen Nr. 8 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101592: No Data. Load from API.  2017-08-08 12:15:57 Robert l?sst den MUSKEL spielen Nr. 4 mit cachito, mAvErICk, Robert, Sly und MasterLex515
GID 101593: No Data. Load from API.  2017-08-08 12:21:57 Robert l?sst den MUSKEL spielen Nr. 4 mit cachito, mAvErICk, Robert, Sly und MasterLex515
GID 101594: No Data. Load from API.  2017-08-08 12:27:58 Robert l?sst den MUSKEL spielen Nr. 10 mit mAvErICk, Robert, cachito, Sly und MasterLex515
GID 101595: No Data. Load from API.  2017-08-08 12:33:58 Robert l?sst den MUSKEL spielen Nr. 6 mit cachito, mAvErICk, Sly, Robert und MasterLex515
GID 101596: No Data. Load from API.  2017-08-08 12:39:58 Robert l?sst den MUSKEL spielen Nr. 2 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101597: No Data. Load from API.  2017-08-08 12:45:58 Robert l?sst den MUSKEL spielen Nr. 8 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101598: No Data. Load from API.  2017-08-08 12:51:59 Robert l?sst den MUSKEL spielen Nr. 8 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101599: No Data. Load from API.  2017-08-08 12:57:59 Robert l?sst den MUSKEL spielen Nr. 2 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101600: No Data. Load from API.  2017-08-08 13:03:59 Robert l?sst den MUSKEL spielen Nr. 1 mit Sly, mAvErICk, Robert, cachito und MasterLex515
GID 101601: No Data. Load from API.  2017-08-08 13:10:00 Robert l?sst den MUSKEL spielen Nr. 2 mit Sly, Robert, mAvErICk, cachito und MasterLex515
GID 101602: No Data. Load from API.  2017-08-08 13:16:00 Robert l?sst den MUSKEL spielen Nr. 4 mit cachito, mAvErICk, Robert, Sly und MasterLex515
GID 101603: No Data. Load from API.  2017-08-08 13:22:00 Robert l?sst den MUSKEL spielen Nr. 5 mit mAvErICk, Robert, Sly, cachito und MasterLex515
GID 101604: No Data. Load from API.  2017-08-08 13:28:00 Robert l?sst den MUSKEL spielen Nr. 4 mit cachito, mAvErICk, Robert, Sly und MasterLex515
GID 101605: No Data. Load from API.  2017-08-08 13:34:01 Robert l?sst den MUSKEL spielen Nr. 6 mit cachito, mAvErICk, Sly, Robert und MasterLex515
GID 101606: No Data. Load from API.  2017-08-08 13:40:01 Robert l?sst den MUSKEL spielen Nr. 1 mit Sly, mAvErICk, Robert, cachito und MasterLex515
GID 101607: No Data. Load from API.  No game.        

Einige Spiele wurden auch mehrfach angelegt. Zuckt.

kili 2017-01-28 23:05:14
Die Vermutung mit der (clientseitig) abgebrochenen Verbindung hatte ich ja auch schon, die erscheint mir plausibel, und das konnte ich ja auch schon mit ps und netstat auf Didis Server beobachten (50 php-Prozesse fuer Karopapier, die offenbar alle auf die Datenbank gewartet haben, aber *nicht* 50 aktive Verbindungen von der gleichen IP-Adresse).

Das mit dem connection_aborted() duerfte vermutlich nicht viel helfen, denn das muesste ja vor den "teuren" Operationen (Datenbankeeintraege fuer das neue Spiel, Spielerstellungslogmessage schreiben) gechecked werden, aber da ist die Verbindung wohl eher noch nicht in den Timeout gelaufen.

Wenn man da serverseitig was machen wollte, muesste man mal wissen, *was* da beim Spielerstellen per API ueberhaupt passiert. Und vor allem, warum dann nur alle paar Minuten ein php-Prozess mit der Spielerstellung fertig wird.

Und was den Client (also den KaroMUSKEL) angeht: ich hatte es schon mal geschrieben: es macht IMHO keinen Sinn, ueberhaupt mit mehreren Threads zu arbeiten. Wenn alles gut laeuft, duerfte eine rein sequentielle Spielerstellung eigentlich genauso gut flutschen, wie parallele Spielererstellungen in mehreren Threads. Und wenn's nicht flutscht, dann klemmt offenbar was, und dan ist es erst recht nicht sinnvoll, noch mehr Spielerstellungsrequests rauszuschieben.

Und wenn der Client in einen Timeout rennt, dann sollte er erstmal gar nichts mehr machen, keine weiteren Requests rausschicken, sondern evtl. noch laufende Requests abwarten (wenn er den multithreaded rennt) und die Infos fuer *moeglicherweise* fehlgeschlagene Spielerstellungen erstmal in einer Queue sammeln und danach mit den noch weiteren zu erstellenden Spielen weitermachen (und auch dort bei Timeouts die Spiele in die Queue packen). Anschliessend koennte er dann mal nachsehen, welche Spiele denn nun erstellt  wurden und dann ggf. die gequeuten Spiele noch mal zu erstellen versuchen.

Auf gar keinen Fall sollte der Client eine Spielerstellung ohne weitere Checks wiederholen, wenn er in einen Timeout oder eine sonstige SocketException (oder was die Java-API da so an Exceptions wirft) gelaufen ist. Weil dann naemlich eben nicht klar ist ob das Spiel erstellt wurde oder nicht.

Ciao,
-- kili

aristarch 2017-01-28 15:50:46
Ich bin technisch nicht versiert genug um deine Theorie zu beurteilen.
Die Auswirkungen beschreibst du jedenfalls richtig, und von dieser Seite klingt für mich alles schlüssig.

Scheiß Autokorrektur... ultimate 2017-01-28 15:41:38
... auf dem Handy hat den Link versaut...

Wilde Theorie ultimate 2017-01-28 15:39:33
Also ich habe mal ein bisschen recherchiert und daraufhin eine Theorie entwickelt, wie das ganze ablaufen könnte. Dazu erstmal ein paar Fakten:

Die Client-Seite (also der teuflische KaroMUSKEL):
- Ich benutze eine Java HttpURLConnection um die Log-Files bzw. Spiele-Seiten zu laden.
- Diese hat zwei verschiedene Timeouts, die man konfigurieren kann (ich benutze die Default-Werte): "connectTimeout" und "readTimeout"

Die Server-Seite (also Karopapier):
- Es ist für einen Endpunkt einer Socket-Verbindung (hier Http) nicht so einfach möglich festzustellen, ob die Verbindung noch offen ist. "Nicht so einfach" heißt genauer, dass der Teilnehmer versuchen muss etwas zu schreiben (oder zu lesen) und wenn dann die Verbindung bereits geschlossen ist, gibt es einen Fehler.
- Dementsprechend arbeitet ein Server in der Regel die Anfrage eines Clients auch dann noch ab, wenn dieser die Verbindung schon längst getrennt hat. Das ist auch in PHP so URL=http://stackoverflow.com/questions/11360274/can-closing-the-browser-terminate-the-php-script-on-the-server Link:-

Nun zu meiner Theorie:
- Beim Erstellen einer Spielserie werden (seit dem Update des KaroMUSKELs) bis zu 10 Threads verzögert gestartet um jeweils einzelne Spiele zu starten
- Die Verzögerung dabei so gewählt, dass die erste Anfrage im Idealfall schon durch sein sollte, bevor der 2. oder 3. Thread gestartet wird. Das ist aber abhängig von der Reaktionszeit des Karo-Servers.
- Nun rennen diese 10 Threads los und verbinden sich fleißig mit dem Karo-Server. Dieser reagiert zwar, hat aber vielleicht einen schlechten Tag und arbeitet daher nicht so flink. Daher sind zwar die 10 Verbindungen aufgebaut, die Abarbeitung dauert aber im kritischen Fall länger als der "readTimeout" der HttpURLConnection, so dass diese die Verbindung zum Server nach Ablauf des Timeouts unterbricht.
- Der Server bekommt dies natürlich nicht mit (siehe oben) und ackert erstmal weiter.
- Nun werdeb im KaroMUSKEL die fehlgeschlagenen Anfragen (mit Verzögerung) wiederholt. Der Karo-Server ist zwar beschäftigt, aber nun auch nicht wieder so stark, dass er keine weiteren Anfragen annimmt. Das hat zur Folge, dass sich das ganze so lange wiederholt, bis die maximale Threadzahl in PHP auf dem Server erreicht ist.
- Der KaroMUSKEL versucht weiter die getimeouteten Anfragen zu Wiederholen, nur dass jetzt gar nichts mehr auf dem Server geht. Die HttpURLConnection scheitert schon bei der Verbindung und der "connectTimeout" greift, da der Servern keine Verbindungen mehr annehmen kann.
- Der KaroMUSKEL versucht es immer weiter - zwar mit größer werdenden Abständen - aber das bringt jetzt alles nix mehr, denn der Server ist überlastet.
- Auch mach einem Beenden/Abschießen des KaroMUSKELs läuft nun auf dem Server noch immer die maximale Anzahl an Threads, die die Anfragen des KaroMUSKELs noch artig abarbeiten.
- Stunden später hat sich der Server dann mal erholt und sie abgearbeitet und die entsprechenden Spiele erstellt.
- Dabei ist es total egal, wie viele Threads im KaroMUSKEL liefen, oder wie groß die Spielserie war - es werden immer genau so viele Spiele erstellt, wie der Karo-Server Threads hat. (Also in unserem Fall 50).

Mögliche Maßnahmen:
- Die Threadzahl im KaroMUSKEL anzupassen hilft vermutlich nicht viel, denn auch ein Thread kann diesen Fehler verursachen, wenn er in die Timeouts läuft.
- Eine mögliche Maßnahme auf KaroMUSKEL-Seite wäre vermutlich eine Erhöhung der Timeouts, damit der KaroMUSKEL dem Server mehr Zeit bei der Abarbeitung gibt und die Verbindung nicht vorschnell beendet.
- Vielleicht ist das auch der Grund, warum es bei aristarch Probleme gibt, bei mir aber nicht. Es könnte sein, dass seine Java Virtual Maschine einfach andere Default-Werte für die Timeouts verwendet als meine (entweder aufgrund des Betriebssystems (Linux vs. Windows) oder aufgrund der anderen VM-Version (OpenJDK vs. normales JDK)).
- Eine Maßnahme auf Karo-Server-Seite, die zwar das Problem nicht behebt, aber die Konsequenzen (nämlich 50 doppelte Spiele in der Datenbank) eliminiert, wäre eventuell eine Prüfung der Verbindung vor dem Ausführen des SQL-Insert-Befehls über connection_aborted(), wie unter -:Link text=diesem Link
beschrieben.

Was meint ihr? Ist das eine mögliche Erklärung?

aristarch 2017-01-15 19:21:09
Als zusätzlicher Zeitstempel kann auch der Chat dienen:

aristarch (10:43): Hier ist ja noch weniger los als an den üblichen Wochenenden. Dann mach ich jetzt ne neue IQ-Serie mit dem Muskel. Nachdem die letzte so schief ging ... das habt ihr nun davon ;-)
cachito (10:57): auja...
aristarch (11:08): Luft anhalten ...
aristarch (11:10): Der Muskel hängt bei "wird erstellt" :-(
aristarch (11:11): Ist hier alles in Ordnung?
aristarch (11:14): Bis jetzt wurde ein einziges Spiel erstellt.
cachito (11:16): KP reagiert sehr langsam...
aristarch (11:18): Ich konnte gar nicht mehr zu greifen. Vielleicht die automatische temporäre IP-Blockade von Didi. Muskel hat nicht mehr reagiert. Habe alles abgeschaltet und Reboot.

Heute wieder... kili 2017-01-15 17:16:38
Mal zur Zusammenfassung der heutigen Erkenntnisse (ist hier besser aufgehoben, als im Chat):

Ari hat heute (15.01.2017) so gegen 11:08 den MUSKEL angeworfen, worauf hin karopapier sofort wieder geklemmt hat.

Als ich mit ps(1) nachgesehen habe, liefen da um die 50 php-fpm Prozesse fuer 'karo', alle isleeping, alle zwischen 11:09 und 11:13 gestartet.

Im Munin wurden etwas mehr als 100 MySQL-Threads angezeigt.

Ari hat das ganze dann abgebrochen, der Karoserver hat aber -- in aeusserst gemuetlichem Tempo -- die 50 angestauten Requests verarbeitet und war dann kurz vor 16:00 Uhr damit fertig.

Hier eine Kopie der Munin-Grafik mit den MySQL-Threads von heute:

http://karopapier.dead-parrot.de/mysql_threads-day.png

Und hier die Spielerstellungszeilen aus den Gamelogs:

http://karopapier.dead-parrot.de/amok-2017-01-15.txt

Ciao,
-- kili

Super, vielen Dank! ultimate 2017-01-08 00:11:55
Soweit ich das in der Konsolen-Ausgabe des Muskels sehe treten aktuell auch keine Probleme mehr auf! Alle Erstellungen laufen sauber und zügig und dabei ohne Fehler durch.

Danke für eure Analyse des Problems und die Tipps! So wird der Karo-Server nun nicht mehr überstrapaziert!

Limits Didi 2017-01-04 13:51:54

Die Begrenzung mache nicht ich oder eines meiner Karo-Scripte, sondern das tool fail2ban, das log files auswertet und konfigurierte Einträge zählt und dann bei Überschreitung eines Grenzwertes zuschlägt. Und das ganz sicher auf IP Ebene.

Wenn der Muskel nun eine Verzögerung hat, dann kann ich das Limit auch wieder etwas entschärfen

:)idi

25 x in 60 Sekunden? ultimate 2016-12-28 14:37:09
... mal ganz im Ernst, das ist aber echt wenig ... !?

Aber eins nach dem anderen:

Ich habe wie versprochen eine neue Version des KaroMUSKELs gebaut und diese steht wie gewohnt im Wiki zur Verfügung.

Dabei muss ich gestehen, dass ich Didis Kommentar erst gelesen habe, nachdem ich schon fertig war, und bin daher etwas verwundert. Ich habe das Thread-Management jetzt nämlich wie folgt konfiguriert :

- Max. Anzahl Threads: 10
- Verzögerung bei erfolgreichem Request oder am Beginn für den Start eines neuen Threads: jeweils 100 ms
(auf diese Weise kommen alle Requests immer nacheinander an und nicht mehr zu Beginn alle gleichzeitig)
- Verzögerung bei nicht erfolgreichem Requests: 500 + (Anzahl der Fehlversuche dieses Threads) * 100 ms
(wachsend bis max. 2000 ms Verzögerung)
- Zusätzliche stoppe ich die Zeit und zähle die Anzahl der fehlgeschlagenen Requests und gebe diese am Ende aus

Das scheint (merkwürdiger Weise - s. o. ich habe das mit den 25 x / 60 sec zu spät gelesen) auch wunderbar zu funktionieren. Für eine Spieleserie von 100 Spielen braucht der KaroMUSKEL jetzt ca. 10 Sekunden mit 0 Fehlversuchen.

Daher jetzt zu meiner Bemerkung vom Anfang:

Ich finde 25 Spiele in 60 Sekunden wirklich wenig. Wenn es danach geht, müsste ich den KaroMUSKEL noch erheblich mehr drosseln und die Verzögerungen vergrößern und das Erstellen großer Spieleserien würde dann ganz schön lange dauern. Zudem ist das so wenig, dass man auf diese Weise (absichtlich oder unabsichtlich) ohne Probleme mal Botrix bannen könnte (vorausgesetzt, sie benutzt die newgame.php), in dem man ein paar Spielanfragen über den Chat stellt.

Ungeachtet der Frage, welche Zahl hier aber nun sinnvoll ist, scheint die Logfile-Überprüfung nicht korrekt zu funktionieren --> siehe oben: 100 Spiele in 10 Sekunden und gebannt wurde ich auch nicht beim Testen. Was mir aber aufgefallen ist, ist die Tatsache, dass nach dem Erstellen der 100 Spiele das Aufrufen der "nur meine Spiele" Seite mit dem Test-Account (CraZZZy) sehr lange gedauert hat, wogegen sie im anderen Browser mit einem anderen Account (ultimate) schnell geladen wurde. Kann es sein, dass du hier nicht die IP, sondern den Account sperrst? Und dass du evtl. die falsche Zeiteinheit benutzt?

Ich bin natürlich daran interessiert den Server nicht unnötig zuzuballern, daher passe ich diese Parameter bei Bedarf auch gerne noch an - ich bin jedoch auch dafür hier nicht zu streng zu sein, damit das mit dem Erstellen der Serien auch weiterhin zügig passieren kann. Mich würde daher auch mal interessieren, was der Server dazu so gesagt hat, während ich in den letzten paar Stunden die Tests gemacht habe. Für weitere Diskussionen bin ich natürlich gerne bereit.

Und nun noch eine letzte Anmerkung:
praktischer Weise funktionieren alle alten Versionen des KaroMUSKELs auch nicht mehr so richtig, da Didi was an der users.php geändert hat und es daher zu Fehlern bei der Initialisierung kommen kann...

| neue Message hinzufügen |
| Anfang | Vorherige | Nächste |

Brought to you by Didi

Letzter Satz im Chat:
eris (17:53): yay! hier gibts das noch interaktiv: https://apolloinrealtime.org/11/