• Videoerzeugungskomponente an das Phänomen angliedern, da dort über measurement requests die sensorpositionen bekannt sind und das raster sonst aufwändig zu übertragen wäre

Birte

• aus dem Phänomen ein Array/Raster aus Double Werten auslesen, skaliert auf bestimmte Größe (z.B. 500,500)

Daniel

Bericht und Besprechen

• phenomen registriert sich mit allen Typen, die es hat, funktioniert, taucht danna auch mehrfach im SensorDictionary auf
• einlesen der verschiedenen blabla.properties in den constants Klassen von Phänomen und Sensor implementiert, geben die jeweiligen SensorWorldProperties zurück, RandomSensorMain sowie PhenomenonMain entsprechend umgestellt
• die Klassen zur Visualisierung etwas überarbeitet, Kompilerwarnungen etc. rausgenommen und umbenannt zur besseren Verständlichkeit
• die Performanceprobleme lagen an der falschen verwendung der BlockingQueue, die nach außen nur als Queue gegeben wurde, und somit auch nur die normalen Operationen einer Queue zuließ. Dadurch griffen CommonConnector und SpecificConnector beide ununterbrochen auf die BlockingQueue zu. Problemlösung: Signaturänderung der Methoden, Rückgabewert: BlockingQeue, dadurch statt normalen poll jetzt ein poll mit timeout ermöglicht, dabei sind auch kurze Intervalle im Bereich weniger Millisekunden mit geringer Prozessorlast möglich.
• die hash() sowie equals() Methode der SensorProperties haben unter anderem die Position des Sensors verwendet, um gleichheit festzustellen... dadurch kann natürlich das Phänomen in seinem dictionary nicht den sich bewegenden Sensor finden, der eine Anfrage gestellt hat. Problemlösung: hash und equals benutzen nur die id des Sensors.
• die persistente Speicherung lässt sich für jeden Producer einzeln einstellen, somit kann auch endlich das Problem mit persistenten verallteten Nachrichten gelöst werden (workaround war: ant builds, welche die entsprechenden Ordner leerten). Lösung: Im CommonConnector sowie in der DictionaryControl gibt es eine Klassenvariable, wodurch die Art der Speicherung global gesetzt werden kann.
• Es treten Probleme auf, wenn sich erst der Sensor und dann die CommSim registriert, da dann der Sensor gar kein Dictionary erhält, und als Folge auch keine update, wenn sich dann die communication simulation registriert. Problemlösung: SensorDictionary wird auch ohne vorhandene CommSim erstellt, eben dieses Feld ist dann null.
• warum vergibt der Sensor selbst eine id? besser: Factory für messages einführen.
• die "direction" in der SensorPositionMessage wird nicht verwendet. bräuchten mal bessere high-level Dokumentation welche Parameter bei Nachrichten optional sind.
• habe die Namen der Komponenten aus der peer-Definitionen raus genommen, nun kann auch ein Sensor mit einer Ip verbunden werden, die vorher ein Phänomen verwendet hat.
• unregister löscht auch gecachte Producer und Destination
• AnyLogger bzw. die any-topics ans laufen bekommen
• deadlock zwischen Komponenten und Konnektoren durch direkte Methodenaufrufe entfernen: Idee: Queue zur Kommunikation für isready, isconnected, register etc.
  • neue Klasse ConnectorStatusMessage mit innerer Enumeration für Status
  • Änderungen an den Interfaces!!!
  • LÄUFT!, auch sicher
    • Kommunikation über ConnectorStatusMessage in PriorityBlockingQueue, wobei antworten auf anfragen eine höhere Priorität haben, da bei requests auf eine Antwort (mit timeout) gewartet wird; da alles mit timeouts versehen ist, sind blockierende Komponenten unwahrscheinlich; Konnektoren kennen sich nurnoch über 4 Queues.
  • wichtige Änderung: erstes Dictionary kommt direkt mit der RegistrationMessage, die als response gesendet wird
• comm sim muss nicht mehr mitgestartet werden, wenn sowieso keine sensor zu sensor Kommunikation stattfindet
• code header von 52North eingefügt

neu

• erweiterte Guis erstellt, die nun high level infos erlauben ("console", buttons für wichtigste Funktionen)
• PhenomenonStarter um einige Optionen erweitert, um komfortabel einen PhenomenonCache zu erstellen oder zu nutzen
• PhenomenonCache geschrieben mit (de)serilisieren, Auswahl des nächstpassenden 2d Array analog zur phen sim dispersion
• getRasterSnapshot durch Threads ordentlich beschleunigt
• RasterCache ist eingebunden und funktioniert, die Visualisierung ist nun RATTENSCHNELL

todo

• dictionary propagation fehler:
  • unregister sensor >> kein neues dict für phen
  • unregister phen >> kein neues dict für sensor
  • bei register, unregister, register wird beim zweiten mal kein dictionary direkt gesendet.

zurückgestellt

• erstellen einer BinaryMessage, die das Versenden von .jpg Dateien zur Visualisierung erlaubt
• einrichten des StatsTopic, dabei kommt NullPointerException zur Laufzeit, da gibt es irgendeinen Fehler
• regelmäßiges (mit Timer), nicht direktes propagieren von neuen IDictionary
• gibt es ein "reset world map"?