Kommunikation

[headnut]

Hallo

Ich möchte meinen aktuellen Gedankengang kurz mit Profis besprechen. Follgende Situation habe ich:

Einen Server über TCP, bei mir ist dies eine SPS

Mein Javaprogramm ist der Client. Als kommunkation habe ich mir protokolle definiert die ich hin und her schicke.

Bei meinem Javaprogramm empfange ich zyklisch die Daten der SPS, jedesmal wenn neue Daten gekommen sind schicke ich diese an meinem Controller, werte sie aus und zeige Sachen in der GUI an.

Da gleiche beim Senden, ich bin immer am Daten senden, bei jeder ändern von der GUI her baue ich meinen String entsprechen zusammen und schicke den der SPS.

Würdet ihr das auch so machen?

 

[irgendjemand]

hmm ... da ich mich mit SPS selbst nicht auskenne ... aber mir vorstellen kann das die technik heute schon so weit ist das da netzwerk-gestützte pc's dran hängen sollte erstmal ne kommunikation mit dem steuer-rechner möglich sein ...
wenn du auch ein eigenes protokoll definiert hast *sofern du das konntest ... ich denke mal du musstest dich da schon nach den vorgaben der SPS richten* musst du dich an dieses halten ..

wenn du in deinem protokoll also vorgesehen hast das jede status-veränderung einer seite dazu führt das eine update-pakete übers netzwerk zum jeweils anderen versand wird ... dann musst du das auch so machen ...

ich persönlich würde jetzt nicht unbedingt bei jeder änderung der SPS informationen schicken ... das sollte auf grund der geschwindigkeit nur der steuer-rechner der SPS selbst übernehmen und in regelmäßigen abständen update-pakete zum clieten schicken ...
natürlich solltest du auch "notfälle" beachten falls der steuer-rechner ein problem feststellt oder das ganze abstürzt ...

beim client würde ich noch z.b. einen button wie UPDATE und SYNC einbauen ... einer um halt veränderungen *als großes paket* komplett an die SPS zu schicken ... anstatt jede einstellung einzeln ... *macht sich vor allem gut wenn du einen haufen steuer-parameter übertragen musst ... anstatt also immer einen geänderten wert zu übertragen und damit eine menge overhead zu erzeugen solltest du lieber erstmal sammeln ...* ... und der andere um explizit ein update von der SPS anzufordern ...

aber im groben und ganzen denke ich das es so gehen sollte ...

 

[JavaProfi]

Ich würde sowas mit einem "Observer-Notification-Model" realisieren.

Die Sensoren melden in zyklischen Abständen Daten (aktive Sensoren) oder werden in zyklischen Abständen abgefragt (passive Sensoren). Wie auch immer.

Die SPS empfängt die Daten und speichert diese in einem Datenmodell auf Serverseite.
Bei jedem Empfang eines Sensordatums überprüft das Datenmodell, ob Daten sich geändert haben.

Wenn ja, so sendet die SPS an alle Clients eine Notification ("hasChanged"). Mehr nicht.
Jeder Client empfängt nun das "Changed-Flag" und entscheidet autonom, ob er z. B. eine GUI aktualisieren muss oder nicht (z.B: weil er gerade etwas anderes macht).

Dazu fragt er beim Server die Daten ab, und zwar nur die, die er benötigt !!!
Die GUIs können ja unterschiedlich sein, je nachdem welche Sicht der Benutzer auf die Daten haben soll.

Jeder GUI ist also ein "Observer" und das Datenmodell implementiert die Schnittstelle "Observable".

Gruß
Der JavaProfi

 

[irgendjemand]

alleine schon die mehrzahl zu verwenden finde ich falsch ...

stell dir mal ne große fabrik vor ... wenn da jede maschine mehrere clienten akzeptieren würde würde innerhalb von 10 min das schönste chaos entstehen ...

in der realität ist es umgekehrt : es gibt einen zentralen "client" *meist der firmen server* der alle maschienen *server* überwacht ...

die einzelnen steuer-clients verbinden sich dabei nicht dierekt mit der sps sondern mit dem server der alles coordiniert ...

außerdem wäre es zu viel traffic nur ein "hasChanged" zu senden und dann von jedem client anzufragen was sich geändert hat *zu mal deine beschreibung den fehler hat : woher soll der client wissen WAS sich geändert hat damit er auch nur die geänderten daten abfragen kann ?* ...
für das netzwerk wäre es hier schonender wenn die SPS als broadcast nicht "hasChanged" sendet sondern *natürlich mit ner ID* dierekt die veränderten werte ...

 

[JavaProfi]

Hallo "irgendjemand"

alleine schon die mehrzahl zu verwenden finde ich falsch ...
stell dir mal ne große fabrik vor ... wenn da jede maschine mehrere clienten akzeptieren würde würde innerhalb von 10 min das schönste chaos entstehen ...

Quatsch! Ich habe schon Systeme auf einem HP-Superdome entwickelt und da hängen 25000 Clients dran, die über eine WAN kommunizieren - und das ohne Chaos! Firmen wie Siemens oder auch BOS können sich heutzutage kein Chaos leisten.

ODER:
Stelle dir eine Messtation für Wetterdaten am Nordpol vor. Die Wetterdaten werden von tausenden Clients abgefragt. Wenn du jetzt alle Clients die geänderten Datens chickst, macht deine Messtation die nächsten Stunden nichts anderes als Nachrichten versenden. In diesem Fall würde ich das System sogar als reines Polling-Verfahren realisieren.

in der realität ist es umgekehrt : es gibt einen zentralen "client" *meist der firmen server* der alle maschienen *server* überwacht ...

Das ist nicht meine Realität in der ich programmiere. Vielleicht leben wir ja in unterschiedlichen Welten? *grins* (Bitte als Scherz verstehe)

die einzelnen steuer-clients verbinden sich dabei nicht dierekt mit der sps sondern mit dem server der alles coordiniert ...

Das kommt auf die Implemtierung an. Es gibt unterschiedliche Arten von Sensornetzwerken.
Eine SPS kann in sehr verschiedener Weise realisiert sein, z. B. als Einzelgerät ("Baugruppe"), als PC-Einsteckkarte, als Softwareemulation, etc. Weit verbreitet sind modulare Lösungen, bei denen die SPS aus einzelnen Steckmodulen (ebenfalls als Baugruppen bezeichnet) zusammengesetzt wird.

Die neueste Generation von SPS sind aktive Sensor-Knoten, die über Funkverbindungen gekoppelt werden. Das würde hier aber den Rahmen sprengen.

außerdem wäre es zu viel traffic nur ein "hasChanged" zu senden und dann von jedem client anzufragen was sich geändert hat

Auch hier wieder eine Frage des Designs eines verteilten Systems.
Sicherlich gibt es Anwendungen, bei denen Broadcasting die richtige Wahl ist.
Was machts du denn bei einem System mit 20000 Clients, wenn sich da im Datenbestand was geändert hat? Allen die geänderten Daten übermitteln? Da ich große Netzwerksysteme programmiere denke ich vielleicht auch anders als in kleinen Firmenstrukturen.

*zu mal deine beschreibung den fehler hat : woher soll der client wissen WAS sich geändert hat damit er auch nur die geänderten daten abfragen kann ?* ...

Oh, vielen Dank für den Hinweis auf einen FEHLER!
Ich schließe daraus, dass du sowas noch nie programmiert hast.
Wenn dich das interessiert, dann empfehle dir folgende Grundlagen: RMI und CORBA und des Weiteren :
Sensor Media Access Control (S-MAC), Timeout Media Access Control (T-MAC), Dozer, SCP-MAC, LMAC, DMAC, TRAMA.

für das netzwerk wäre es hier schonender wenn die SPS als broadcast nicht "hasChanged" sendet sondern *natürlich mit ner ID* dierekt die veränderten werte ...

??? Woher stammt denn diese Weisheit.
Es gibt da keine Allgemeingültigkeit. Weder für noch gegen eine Broadcast-Lösung. Es ist immer eine Frage des zu implementierenden Systems. Aber ich möchte das hier beenden, da wir offensichtlich in total anderen Systemwelten unterwegs sind.

 

[irgendjemand]

mal ein ganz blödes beispiel

du bekommst *von was für einem dienst auch immer* nur die information

"irgendwas hat sich geändert"

folglich muss der client erstmal nachfragen

"ja , was hat sich denn geändert ?"

daraufhin kann dann der dienst entweder dierekt die geänderten daten senden oder , um noch mehr overhead zu erzeugen , nur eine liste der felder die sich geändert haben ... worauf diese natürlich vom client abgefragt werden müssen ...

meinst du nicht das man sich hier einigen overhead sparen könnte in dem der dienst gleich die geänderten daten sendet ... anstatt erstmal bekannt zu geben das sich irgendwas geändert hat ?

wenn wir das ganze in einem IP-netz mal ausrechnen kommt man auf einigen overhead da es ja eine mindestgröße für IP-pakete gibt ...
auch wenn das im endeffekt nur einige bytes sind ... ist es rein rechnerisch effektiver direkt die veränderten daten zu senden ... natürlich jeder wert mit einer ID versehen ...

dadurch spart man folgenden overhead
-meldung das sich was geändert hat
-nachfrage was sich geändert hat
-liste mit IDs der geänderten felder
-abfrage der werte der einzelnen felder ...

und wenn wir dann mal dein beispiel mit mehreren tausenden clienten nehmen ... dann kommt da einiges an overhead zusammen den man sich sparen kann ...
in diesem fall würde ich also deine erklärung , das der dienst erstmal nur ein info-paket schickt das sich überhaupt irgendwas geändert hat und die sich daran anschließende kette von overhead als schlichten designfehler bemängeln und so weder umsetzen noch mir überhaupt weiter den stack ansehen ...
krass nach dem motto : too long , did not listen ...


auch hast du nicht ganz verstanden wie ich das mit den mehreren clients und dem chaos meinte

stellen wir uns mal als beispiel eine CNC-maschine vor ...
alleine nur um irgendwelche sensor-daten abzufragen *werkeug , position , forschritt* mag ja deine idee noch ganz logisch klingen ...

aber spätestens bei der STEUERUNG dieser parameter würde es krachen wenn z.b. client A sagt : nun nimm mal werkzeug 6 und fahr an position x:y:z und führe folgende aktion aus ... und client B dann sagt : nö ich will aber werkzeug 2 an postion a:b:c mit dieser aktion ...

was genau soll dann die CNC machen ?
hier fehlt also eindeutig eine instanz die diese steuerungsinformationen coordiniert ...
ob das ganze nun software mäßig dierekt auf der CNC gelöst ist ... oder wie in meinem beispiel durch einen extra rechner ... das ist gleichgültig ...


zum beispiel deiner wetterstation

meinst du nicht auch das es irgendwie sinnvoller wäre von EINEM rechner die daten abzufragen und dann über ein system welches die kapazitäten besitzt die informationen zu verteilen anstatt die clienten dierekt zum dienst zu verbinden ?
ich spiele damit wieder bewusst auf mein beispiell mit einem kontroll-server an *in diesem fall natürlich ein cluster mit entsprechendem upload* ...


was die "realität" angeht ...
gut ... wenn du der auffassung bist von jedem client eine dierekte verbindung zum dienst aufzubauen ... mag sein das es anwendungsfälle gibt in denen das durchaus besser ist ...
aber wenn du zu mir sagst das ich angeblich keine ahung von SPS hätte ... dann standest du noch nie in einer großen CNC produktions-halle wo es bei dieser lösung zum oben angesprochenen problem führen würde *musste sowas leider schon selbst erleben weil solche "IT-profis" wie du mit einer ähnlichen einstellungen und herangehensweise meinten das netz mal eben umstrukturieren zu wollen*
der finanzielle schaden der durch einen so banalen konzept-fehler enstehen kann lohnt den aufwand sich zu überlegen ob man nicht ein anderes konzept verwenden sollte ...

wenn du jetzt mit deinem sensor-only beispiel weiter machst : klar ist es sinnvoller sich sensor-daten dierekt abzufragen ... sage ich auch nichts gegen ... mein post war lediglich zum punkt steuerung gedacht und das es hier ohne nötige schutzmaßnahmen ganz dolle krachen kann


und was "broadcasting" in "riesen" netzen *größe CLASS-A *ja .. kommt schon .. flamed mich wieder das heute keiner mehr in netzklassen denkt ... danke im voraus** angeht : ich denke schon das es effektiver ist wenn von der netz-infrastruktur ein paket an alle gesendet wird ansatt das zig tausende pakete von jedem client einzeln durchs netz laufen ...
das ist ja der vorteil an broadcasting : das sich um dessen verteilung die *hoffentlich nach standards implementierte* netz-infrastruktur kümmert ... und nicht der programmierer mit seiner software ...
vielleicht denkst du jetzt : ja gut ... hat aber wenig sinn wenn du mit broadcasting hunderte von "diensten" verteilst ... gebe ich dir auch soweit recht ... da wäre es wieder sinnvoller wenn sich die clienten nur die infos holen die sie brauchen ... würde den traffic auf jedenfall geringer halten das das netz mit broadcasts zu flooden


die größe des netzes spielt eigentlich nur eine sehr kleine rolle ...
warum ? nun : für ein "kleines" netz braucht man nur wenige komponenten aus "der mittelklasse" ...
bei einem großen sollte man natürlich mehr komponenten verwenden *und auch aus der "gehobenen" bis "high-end" klasse* ...
die auswirkungen auf den anwendungsfall selbst sollte dabei gering ausfallen ... zumindest wenn man eine anwendung so programmiert das sie ohne änderungen belibig skalirbar ist ...


alles in allem fand ich deine post dann doch aber sehr "beschrenkt" ... da du dich lediglich auf EIN gebiet , nämlich die erfassung von sensordaten konzentriert hast ...
auch wenn ich mich nicht so gut mit SPS auskenne ... weis ich jedoch das es noch deutlich mehr anwendungsbereich gibt die du mit deiner lösung nicht beachtet hast und vermutlich so auch nur schlecht umsetzen können wirst ... egal ob 10 oder 10 millionen netz-teilnehmer

 

[JavaProfi]

ohne Kommentar !! Ich denke mir einfach nur meinen Teil !

 

[irgendjemand]

nö komm sach an ... will ich jetzt wissen ...

*wie ich solche phreaks liebe ... erst ne diskusion lostreten ... und dann keine argumente mehr haben*

 

[Marcinek]

Verstehe ich nicht, was da jetzt schlimm dran ist.

Eine Diskussion zwischen zwei Anonymen Usern.
Einer mit Erfahrung und der andere mit gefährlichem Halbwissen zur Thematik.

Ich finde auch, dass hier alles gesagt worden ist.

Alles andere würde eine Endlosdiskussion führen und dafür sind wir ja nicht hier.

Denk du dir deinen Teil und alles ist supi.