Zitat Zitat von NumberFive
Aber wir müssen auf passen hier vermische sich gerade zwei dinge ich
will mal versuche das zu beschreiben was ich da gerade so sehe.
@NumberFive:
Nein, ganz im Gegenteil. Wir trennen hier gerade Dinge, die eigentlich
nichts miteinander zu tun haben. Wenn ich dich richtig verstanden habe,
dann willst du sagen, daß synchronisierte Variablen für einen Client
wesentlich einfacher zu verwenden sind als Nachrichten, Broadcasts, etc.
Der Client möchte sich nicht darum kümmern, wie die Variablen übertragen
und synchronisiert werden.

Was PicNick meiner Meinung nach erklären will, ist daß die Synchronisierung
von Variablen nur über Nachrichten geht. Diese können versteckt und unsichtbar
laufen, trotzdem existieren sie. Ein Beispiel in smirs: wenn ein Modul eine
Variable setzt, dann wird intern (innerhalb der MC) eine Nachricht an alle
anderen MCs generiert, die über diese Änderung informiert.

Die MCs von smirs sind also ein Dienst, bei dem ein Modul synchronisierte
Variablen anfragen kann. Die Client-Schnittstelle sind TCP/IP Nachrichten,
die interne Kommunikation sind (vmtl) auch TCP/IP Nachrichten.

Auf was ich hinauswill ist folgendes:
Die Synchronisation von Variablen erfordert Nachrichten, sowohl von den
Clients(Modulen) als auch zwischen den Servern(MCs). Man kann also eindeutig
zwei Schichten trennen.
  • 1.) Der eigentliche Transport der Nachrichten
    Dieser beinhaltet die Adressierung der verschiedenen MCs sowie die
    verwendeten Kommunikationsprotokolle (in diesem Fall TCP/IP).

    2.) Der Inhalt der Nachrichten (Semantik)
    z.B. SetVar XXX YYY und der Synchronisationsalgorithmus


Konsequenterweise sollten alle Teilnehmer (also auch die MCs) untereinander
dasselbe Kommunikationsmodell verwenden und allseitig klar definierte
Schnittstellen verwenden. Erweitert man das Kommunikationsmodell, dann
wird erreichen diese Erweiterungen automatisch alle Teilnehmer, ohne daß
diese aufwändig umgeschrieben werden müssen. Man kann also z.B. das
Kommunikationsmodell (bisher bei smirs: TCP/IP) um eine serielle
Komponente erweitern, ohne daß die bisherigen Dienste ihr Funktion
einstellen.

In Ansätzen ist dieses Kommunikationsmodell bei smirs auch zu
erkennen. Knoten werden über MC->Modul adressiert. Nur leider ist
dieses Kommunikationsmodell eben nicht konsequent ausgeführt, denn
die MCs untereinander kommunizieren (Annahme meinerseits) nicht über
ihr internes Kommunikationsmodell (MC->Modul), sondern direkt über
TCP/IP. Damit kann die Kommunikation zwischen zwei MCs nicht einfach
durch eine Erweiterung des Kommunikationsmodells erreicht werden,
sondern nur durch aufwändige Erweiterung aller Einzelkomponenten.

Anmerkung dazu:
Bei smirs muss bei SetVar/GetVar keine Adressierung angegeben werden.
Das ist natürlich praktisch, schließlich will man mit genau einem
(dem nächsten, dem eigenen) MC kommunizieren. Im Prinzip ist das
ganze eine Kommunikation mit einen implizit vorgegebenem Teilnehmer.

Anmerkung 2:
Hat man dieses Kommunikationsmodell, dann kann man es auch direkt
zur Kommunikation zwischen den Komponenten nutzen. Bei smirs ist
die Nachrichtenübertragung sozusagen ja auch ein 'Dienst', nämlich
der Dienst 'BROADCAST' bzw. 'TRANSFER'.


So, ich hoffe ich habe dir jetzt klarmachen können, warum wir
unbedingt die Trennung zwischen Kommunikationsschicht(en) und
Diensteschicht brauchen. Ich will die synchronisieren Variablen
nicht abschaffen, ich will sie nur auf ein gutes (universelles)
Fundament stellen.

ciao,
Georg

BTW: Ich werde demnächst nochmal darauf zurückkommen, wie man
smirs in mein Schichtenmodell einordnen könnte. Ich kann nur
nicht alles auf einmal schreiben.

PS@marvin42x:
Danke für die Illustration zum Schichtenmodell, ist IMHO ein
gutes Beispiel.