SensorWorldProperties
schreiben, Klasse zum versenden von Properties ohne jegliche Referenz (durch klonen und getValue o.Ä.) auf das eigentliche Objekt, jeweils Unterklasse für jede Komponente
CommonConnector
auch die Consumer und Producer in jeweils einer Map vorhalten, analog zu Destinations. Map<Destination, Producer>
und dann immer nur getProducer(Destination d) aufrufen und dort entweder Vorhandenen zurückgeben oder neu instanziieren. (hab ich mal so geändert, finde ich auch besser(Birte)
Map<Destination, Consumer>
, (Methode analog bei der registration() würde ich schon direkt den consumer erzeugen lassen, anstatt den Umweg über das Dictionary zu gehen(Birte))
Peer
{1,2} .java
, vielleicht auch mit Maven (http://maven.apache.org/what-is-maven.html)
: Rechner finden sich nach ca. 15 Minuten, dann Probleme bei Registrierung, die registration_queue
ist mehrfach vorhanden; statische Queue registration_destination
im vcl Peer, dann funktioniert die Registrierung
: wiederholt Fehler: "agent already exists, doing nothing"
auf einem Rechner, regqueue nicht statisch: Registrierung von commsim und phen erfolgreich(!) A peer named <...> tried to connect, but does not appear in the world map. Closing connection <...>
exit()
- Methoden, die ordentlich die Connections und Requests und so weiter schließen
ThreadGroup
zur Organisation der Threads? Vll. eine Gruppe pro Sensor - Instanz?
insertMessage
- Methoden mehr im CC
gibt, wird die Behandlung von fehlenden Informationen in die SC
verlagert, was auch Sinn macht, da dort dann analog zu den überhaupt existierenden Anwendungsfällen bzw. zum existierenden Mapping im jeweiligen IDictionary
eine Fehlerbehandlung bzw. Fehlerwerfen eingerichtet werden kann. Z.B. könnte sendMessage
ohne recipients im PhenomenConnector
gleich eine IllegalArgumentException
werfen.
CommunicationSimulation
sollte einen (limitieren) Pool an Threads haben, die die Anfragen parallel arbarbeiten, in Analogie zu ServerSocket, das ein neues Socket erzeugt, sobald eine Anfrage kommt und weiter lauscht. Kommt dann darauf an, wie aufwändig die Berechnungen zur Erreichbarkeit sind.
int
, später mal eine PhenomenonTypeRegistry
mit encode(String lala)
und decode(int i)
DestinationNameFactory.getQeueForAnything()
das Argument Class<? extends ISpecificConnector> c
eingefügt
= hinzufügend, siehe =replace(...)
in TasksOne, außerdem gibt es ja delete(...)
MantaSession
, Zeile 919, Selector s = new Selector(messageSelector);
... habe antlr.jar in den lib ordner gepackt ... mit dieser auf dem classpath kommt der Fehler nicht mehr! ... die war im letzen Projekt auch drin, und inzwischen meine ich mich zu erinnern, dass ich die dort auch hingepackt habe, da mir die antlr - Hompage irgendwie bekannt vorkam. Aber hiermit ist das ja angemessen dokumentiert.
RegistrationMessage
und die entsprechenden Methoden aus DictinaryControl
entfernt
ObjectMessage
verpackt werden sollen, auch Serializable
implementieren müssen. Nichtsdestotrotz sollten Sensor etc. nicht Serializable implementieren, sondern wirklich nur Objekte, die wir hin und her schicken.
DictionaryMessages
mit dem Task NEW_DICTIONARY versendet
Serilizable
Interface implementiert wurde ... finde das allerdings auch eine hinreichende Begründung für die Existenz von SensorWorldProperties
. Habe aus diesem Grunde auch die Folgenden änderungen gemacht, weil diese in einigen Nachrichten verwendet werden Geometry extends Serializable
Measurement implements Serializable
SC
und CC
kommunizieren über zwei Queues, QueueSC
und CC
müssen auf einer Ebene als unabhängige Threads laufen, deswegen wir der Konstruktor vom SC
um einen ExecutorService
erweitert, mit dem der zugehörige CC
(oder auch weitere Threads) dann ausgeführt wird. Jede Komponente muss selbst managen, dass die Vernünftig als Threads parallel laufen.
RegistrationMessages
kann doch eigentlich aus der onMessage()
des CC
raus, weil das ja über einen request in der Methode register()
geregelt wird.
sendMessage(SWM msg, int[] recs)
zu sendMessages(SWM msg, int[] recs)
ändern um klarer unterscheiden zu können
CC
sonst auch tun. Um dieser Tatsache gerecht zu werden, wird eine isReady
Methode in beide Connectoren eingearbeitet, die dem Verwender (Highlevel-Komponente) Information darüber liefert, ob eine Nachrichtenabarbeitung stattfinden kann. Auch wenn der SC
nicht ready ist, können Nachrichten gesendet werden, diese bleiben dann jedoch in der Queue vom SC
zum CC
. Die verwendende Komponente kann dann selbst entscheiden, ob sie auf den ready - state des SC
wartet oder nicht. Der SC
ist ready gdw. der zugehörige CC
ready ist und möglicherweise noch weitere Kriterien. Der CC
ist ready gdw. er sich erfolgreich registriert hat und damit auch initialisiert ist.
miniGUI
erstellt für Phenomen und Sensor, dadurch kann man den vcl und die commsim laufen lassen, wenn man am Phänomen oder am Sensor arbeitet und letztere registrieren, den sensor starten und stoppen, bei "gracefully" beenden. Dafür einige Methoden in die Abstract{Phenomenon,Sensor}Simulation
hinzugefügt, die dann auch public sein mussten, finde das so aber schöner gekapselt als wenn die GUI in der Klasse drinhängt. Außerdem Änderungen an ICommonConnector
und ISpecificConnector
notwendig.