Beschreibung

Fast die gesamten Hintergrundvorgänge im Comm-Modul werden durch Signalhandler gesteuert und auf Kosten der Interrupts ausgeführt. Lediglich das Beschreiben des actionBuffer (prepareXYZ()-Methoden) und Abfrage der Eigenschaften des Comm-Moduls (getServerTime(), getMyNumber(), getNextData(), getNextMsg(), etc.) werden wirklich vom Agenten ausgelöst und mit seiner Rechenzeit ausgeführt.

Die Hintergrundvorgänge lassen sich wiederum in zwei Klassen einteilen:

• Die von SIGALRM ausgelösten Vorgänge (siehe alarmAction(), Abschnitt)

Steht das Spiel, so übernimmt alarmAction() alle SIMULATOR_STEP Millisekunden das Versenden des actionBuffer. Die Alarmzeit wird bei Nachrichten während des stehenden Spiels nicht zurückgesetzt.

Bei laufendem Spiel wird alarmAction() nur dann aufgerufen, wenn länger als SIMULATOR_STEP+ALARM_MARGIN Millisekunden keine Nachricht vom Server empfangen wurde. Spätestens nach dieser Zeit muß der Agent davon ausgehen, daß sich der Server in einem neuen Zyklus befindet. In dieser Methode wird geprüft, ob der Server nicht schon tot ist (d.h. länger als 40 Simulationsschritte nichts gesendet hat). Bei eingeschalteter losingPackets-Option wird hier außerdem ein Zyklenwechsel forciert, ohne neue Nachrichten vom Server empfangen zu haben. Dies ist zwar unsicherer, als auf die neue Nachricht vom Server zu warten, aber nötig, wenn nicht garantiert ist, daß diese Nachricht überhaupt ankommt. Bei forciertem Zyklenwechsel wird natürlich, wie bei normalen Zyklenwechseln auch, die actionBuffer an den Server gesendet.

• Die von SIGIO ausgelösten Vorgänge (siehe ioAction(), Abschnitt)

Die von SIGIO ausgelösten Vorgänge sind etwas umfangreicher: Es werden alle Nachrichten, die am Socket anliegen, nacheinander eingelesen und vorverarbeitet (geparst bzw. decodiert). Bei jeder Nachricht während eines laufenden Spiels wird dabei der Alarm zurückgesetzt auf SIMULATOR_STEP+ALARM_MARGIN. Daduch wird der Alarm bei laufendem Spiel nur genau dann ausgelöst, wenn für einen längeren Zeitraum keine Nachrichten empfangen wurden (das erste Mal nach SIMULATOR_STEP+ALARM_MARGIN Millisekunden, dann alle SIMULATOR_STEP Millisekunden). Hat sich beim Parsen einer Nachricht der PlayMode verändert, so wird er gleich aktualisiert. Danach wird die Serverzeit entsprechend der neuen Nachricht aktualisiert und dabei ggf. gleich der actionBuffer gesendet, falls der Server in einem neuen Schritt ist. Beim Aktualisieren der Serverzeit werden auch Serverzyklen, in denen wir keine Nachricht vom Server erhalten haben, als Fehler angezeigt, und weiterhin auch eine zu stark oder schwach forcierte Serverzeit wieder korrigiert (jeweils mit Fehlermeldung). Ist eine Nachricht eines anderen Spielers gehört worden, so wird sie decodiert und gequeued. Alle anderen Nachrichten werden in die SensorElement Schlange geschrieben, aus der sie mit getNextData() von anderen Objekten (Worldmodel) wieder ausgelesen werden können.