Kommunikation

[Roland Ziegler]

Aus dem "Use Case" Thread ( http://zusiforum.eisenbahn-seiten.de/vi ... 9835#99835 ):

Mein vorschlag - schon im Sinne der Trafficbegrenzung vom/zum Zusi-Hauptprogramm sollte ein Stellwerksprogramm für einen Bahnhof die Verantwortung übernehmen.
Von dem Fahrdienstleiterstellwerk/programm können dann je nach Konfiguration mehrere Clients dranhängen die ihre Eingaben nur an ihr direktes Fahrdienstleiterstellwerk schicken. Hat den Vorteil, daß für Zusi alle Stellwerke gleich sind und damit jeder Bahnhof auch durch beliebige Stellwerke besetzt werden können. Für die LAN-Party also mit 3 mech. Stellwerken und für den Einzelspieler als ESTW oder B/W Kombination.
Der Nachteil besteht in doch länger werdenden Laufzeiten der Befehle. Ein Befehl zur Weichenumstellung (die ja dann unabhängig von Fahrstraßen umgelegt werden können) würde im Extremfall erst vom Stw.client zum Stw.server (Fdl-Stellwerk) gehen und dann weiter zum Zusi-Hauptrechner. Von dort gehts dann weiter über die Darstellung zum Nutzer. Dürfte aber nicht weiter schlimm sein, da man ja - zumindest ab den Gleisbildstellwerken - mit Weichenumlaufzeiten von mindestens 6 sekunden rechnet.

P.S: Da hier Ansätze für Netzwerkfunktionen im Zusi kommen will ich mal darauf hinweisen, daß man auch einen Beobachtermodus für Zusi benötigen wird. Speziell für die Stellwerks'zuschauer' brauch man schon weniger Informationen zum Darstellen der gewünschten Sicht.

Zum Kommunikationsserver:

Das Datenaufkommen hier wird minimal sein, die Laufzeiten beim zunächst verfolgten synchronen Modell ebenfalls.

Reine Monitor-Funktionalität ist vorstellbar, würde aber größere Mitwirkung von Zusi bedingen, wenn Stellwerke beobachtet werden sollen, die unter Zusi-Hoheit liegen. Möchte ich für die Entwicklung zunächst zurückstellen.

Genauso Rückmeldeverzögerungen. Die sind natürlich machbar, haben aber evtl wieder Einfluss auf den erforderlichen Umfang der Zusi-Mitwirkung, und verkomplizieren zunächst durch die asynchrone Komponente die Kommunikation, ohne etwas Wesentliches zur Grundlogik beizutragen. Daher nach Möglichkeit auch später. Die Architektur sollte diesbezügliche Erweiterungen aber problemlos verkraften können.

Der Kommunikationsserver aber sollte erst einmal im Prinzip funktionieren. Da hier bei der Umsetzung möglichst wenig Räder neu erfunden, und fertige Technologien eingesetzt werden sollen, wird hier wohl zunächst eine Prototypentwicklung anstehen, die einem Bottom-Up-Ansatz folgen wird.

[Max Senft]

Hühott.

Bin mir jetz grad nich so ganz im klaren wo die Vorteile eines Zwischenservers liegen? stuvar hatte den Traffic angesprochen, aber ist der nicht der selbe? *amkopfkratz*

Bzgl. der Rückmeldeverzögerung: Wieso nicht etwas tricksen und das eigentliche Kommando erst ein paar Sekunden im Stellwerksprogramm "festhalten", aber z.b. die Weichenumlegeanimation schon starten.

Und wenn mans wirklich realistisch will (Verrückte Idee von AndiK): Programm "Weiche.exe" schreiben, das einem eine weiche so physikalisch realistisch wie möglich simuliert. Da kommt die Verzögerung von selbst.

Bye
Max Senft

[Andreas Karg]

Verrückte Idee von mir? Hab ich Alzheimer oder einfach nur so viele verrückte Ideen, dass ich manche schon wieder vergessen hab? Wovon ich die ganze Zeit geredet hab, das ist die "Verzögerung" durch eine laufende ANIMATION!
Das heißt, Zusi krieg Befehl "Lege Weiche sowieso um" und zusi legt die Weiche mit der passenden Animation um. Wenn die durchgelaufen ist gibt es ne Rückmeldung und fertig ist die Laube. Oder die Fahrstraße, oder doch wenigstens ein Teil davon.

[Roland Ziegler]

Der Zwischenserver wird nach jetzigen Überlegungen ein virtueller sein.

Zusi selbst verfügt bislang über keine Server-Infrastruktur. Das ist m.E. auch nicht Aufgabe von Zusi. Deswegen soll eine neue und dedizierte Komponente all die Kommunikationsaufgaben zentral verwalten, und sich dabei soweit wie möglich transparent verhalten.

Zusi könnte sich bei diesem Kommunikationsserver wiederum als (spezieller) Client anmelden. Der Kommunikationsserver muss aber kein eigenständiger Prozess sein, sondern kann genauso und m.E. einfacher zu handhaben als Lib im Zusi-Prozess laufen.

Was das asynchrone Verhalten angeht: Als großer Gegner jedweder Wasserfallmodelle möchte ich solche Funktionalität bewusst zurückstellen. Sie macht einiges komplizierter - z.B. müssten wegen der dann existierenden transienten Zustände praktisch alle Stellwerksobjekte schon zu Anfang eine kleine State-Machine bekommen - , ohne substantiell groß etwas zum System beizutragen. Es handelt sich um, - darin sind wir uns ja sicher einig - trotz aller Hübschheit funktional gesehen um Kosmetik.

Mir geht es vielmehr darum, zunächst "einen Weg durch den Wald" zu finden, und ein Grundgerüst zu erstellen. Die Architektur dafür soll entsprechend tragfähig sein, und nicht mit jeder Erweiterung gleich gekippt werden müssen. Wenn das dann steht, und erste Daten hin- und her flitzen, dann kann man gern darüber reden, welches Kapitel von den vielen dann als nächstes angepackt wird.

Übrigens: Zusi läuft ja im "Primitivmodus" für DirectX, also praktsich 100% CPU-Belastung durch Endlosschleife - es sei denn, ein Frameratenbegrenzer ist aktiv. Aber auch dann folgt Zusi einem simplen zeitgesteuerten Polling-Modell. Das Stellwerk hingegen wird einem Ereignismodell folgen. Richtig umgesetzt, wird es minimale Systembelastung hervorrufen. Diese unterschiedlichen Modelle haben duchaus Auswirkungen auf Verarbeitung asynchroner Ereignisse.

[Max Senft]

Bzgl. des Kommunikationsservers: Den gibts doch schon von Daniel Schuhmann!? Dort meldet sich Zusi schließlich auch als Client an usw. Also an für sich genau das was du willst, oder hab ich noch ein Detail verpeilt?

Bye
Max Senft

[Michael_Poschmann]

...Als großer Gegner jedweder Wasserfallmodelle ...

... möchte ich solche Funktionalität bewusst zurückstellen.

Roland ist mir ein wenig zuvorgekommen. Als ich den Wunsch nach animierter Weichenumstellung gelesen habe, war ebenfalls mein erster Gedanke, sich zu Beginn einer Realisierung auf das Wesentliche zu beschränken. Auch bei Zusi war am Anfang der Entwicklung nicht jedes Detail ausmodelliert (z.B. "Schuhkartons" in rot und grün als Fahrzeuge), andernfalls würden wir heute noch auf die erste Demo warten.
Daher meine Bitte: Schreibt all die netten Funktionen und "Fietschers" auf einen Bierdeckel, so daß sie nicht vergessen werden, und helft ansonsten mit, daß in absehbarer Zeit ein erster lauffähiger Ansatz die Grundsätze des Stellwerksbetriebs darstellt.
Aus meiner Erfahrung ist nichts schlimmer als ein Mammutvorhaben, bei dem man sich in Details verzettelt und nach zwei Jahren ohne vorzeigbare Ergebnisse die Lust verliert.

Gruß
Michael

[Daniel Rüscher aka Merlin]

Prinzipiell ja, Praktisch und Technisch Nein. Der Server braucht nen komplett neuen Befehlssatz und andere Funktionen (Prioretierung). Anpassen käme da wohl Neuschreiben gleich. Abgesehen davon liegt der Fokus hier eher auf Zusi3, das Zusi2 Modell umzubiegen dürfte sich als zu Aufwändig gestallten, als das der Aufwand als gerechtfertigt erscheint.
Zumindest meine Meinung.

Gruß Daniel

[Roland Ziegler]

Der Server braucht nen komplett neuen Befehlssatz und andere Funktionen (Prioretierung). Anpassen käme da wohl Neuschreiben gleich.

Hmmh. Nichts gegen konstruktive Kritik. Aber diesen Einwand müsstest Du schon ein wenig erläutern. Die entsprechenden Server, die ich bisher gebaut habe, wurden für solche Erweiterungen nämlich nicht neu geschrieben.

[Daniel Rüscher aka Merlin]

Naja ist nicht wirklich Kritik. Der ZusiServer so wie ich ihn bis jetzt verstanden habe kann ja nur Daten Sammeln und zu Zusi Schicken (Umgedreht natürlich auch). Für das Stellwerk muss er aber auch Daten zwischen den einzelnen Stellwerken hin und herschicken können. Oder versteh ich da was falsch?
Desweiteren wäre es auch realitätsnah wenn man bestimmten Stellbefehlen Prioritäten gibt um sie schneller ausführen zu können (HaGT also Signalhaltfalltaste zum Beispiel, da Sicherheitsrelevant).
Desweitern muss der Server ja auch einen Kommunikationskanal für die Stellwerksbeobachtung haben (Wie auch immer geartet, ob man jetzt Bilderr direkt verschickt, oder Der DirectX-Einheit im Stellwerk nur die Notwendigen Daten wie Position oder das Objekt direkt).

Das meinte ich damit. Wenn natürlich bei mir da ein Verständnissproblem vorliegt kann mein Kommentar natürlich wieder vergessen werden.

Gruß Daniel

[Daniel Rüscher aka Merlin]

Auch nochmal zu Michael: Ich muss dir Beipflichten: Ziel ist es hier immernoch eine Software auszudenken die vorerst nur Signale grün werden lässt, ABER auch für Sachen wie animierte Weichen oder den Anschluss von Ansagenanlagen für Bahnsteige oder auch Netzwerkfunktionalitäten vorbereitet ist. Drum auch die Modularisierung: Das Programm ruft nur die dll Weiche auf. und wartet auf die Rückantwort. Was in der drinsteht ist primär egal.
Also Feature merken und zur gegebenen Zeit(Vor Release X) nochmal vorschlagen.
Mit kleinen Schritten kommat man ja bekanntlich auch ans Ziel, stolpert aber nicht so schnell.

Gruß Daniel

[Christopher Spies]

Sehe ich es richtig, dass somit jedes einzelne Stellwerk eine eigene Instanz bilden soll, und die einzelnen Instanzen untereinander über einen Socket kommunizieren, auch wenn sie auf dem gleichen Rechner liegen?

Muss dann für jedes zu steuernde Stellwerk eine neue Instanz des Stellwerkssimulators gestartet werden?

- Christopher

[stuvar]

Genauso Rückmeldeverzögerungen. Die sind natürlich machbar, haben aber evtl wieder Einfluss auf den erforderlichen Umfang der Zusi-Mitwirkung, und verkomplizieren zunächst durch die asynchrone Komponente die Kommunikation, ohne etwas Wesentliches zur Grundlogik beizutragen. Daher nach Möglichkeit auch später. Die Architektur sollte diesbezügliche Erweiterungen aber problemlos verkraften können.

Ich meinte zwar keine künstlich eingebauten Verzögerungen, sondern die Verzögerungen die durch den Transport der Daten im Netzwerk entstehen.

Reine Monitor-Funktionalität ist vorstellbar, würde aber größere Mitwirkung von Zusi bedingen, wenn Stellwerke beobachtet werden sollen, die unter Zusi-Hoheit liegen. Möchte ich für die Entwicklung zunächst zurückstellen.

Nein, das Stellwerk selber soll nicht beobachtet werden. Man kann doch schon jetzt in Zusi sich einen der vordefinierten Punkte in der Landschaft aussuchen und von dort aus den Bahnverkehr beobachten. Mit Beobachtungsmodus meine ich 'das Fenster aus dem der Stellwerker (Spieler) rausschaut'. Man startet quasi Zusi im Beobachtermodus und darf gar keinen Zug auswählen, sondern nur einen Landschaftspunkt.


Bezüglich der Kommunikation hast du mit den vertikalen und horizontalen Schnittstellen genau die richtige Beschreibung genommen. Was ein Stellwerk an der Zusi-Umwelt manipuliert muß direkt mit dem Zusi-Kommunikationsserver abgesprochen werden. Was die Stellwerke untereinander besprechen (Bahnhofsblock etc.) sollte nicht über diesen Server gehen (es sei denn eines der Stellwerke wird von Zusi bedient).

Ein Problem mit dem man sich noch befassen muß ist (Ich erwarte keine Antwort. Man muß nur beachten, daß die Entscheidung jetzt Auswirkungen auf die Machbarkeit - und den Arbeitsaufwand - der folgenden Varianten hat): Wie will ich das Spiel überhaupt starten? Warten bis alle Mitspieler eingelogt sind und dann den Fahrsimulator starten? Bedeutet aber auch, daß F9 und F11 gesperrt werden müssen. Und bedeutet ggf. auch enorme Wartezeiten vor dem Spielstart für den jeweiligen Mitspieler. Oder sollen Mitfahrer oder neue Stellwerksbediener auch später mit einsteigen können?

[Roland Ziegler]

@Max:

Das direkte Aufsetzen auf Sockets macht es für Anwendungsentwickler schon etwas kompliziert. Man muss dann sinnvollerweise erst mal Client-Libs schreiben, die die Sockets kapseln. Und sich für praktisch jeden Datentyp um das Marshaling kümmern (Serialisierung). Solches würde ich gern vermeiden, und auf OO-Lösungen gehen, die deratige Client-Libs gleich mit enthalten bzw vermeiden. Technologien wären hier z.B. CORBA, COM, .Net-Remoting oder Enterprise Java Beans.

Mir schwebt da inzwischen ein sehr konkreter Lösungsansatz vor. Der muss jedoch erst mal ausprobiert werden - Machbarkeitsprüfung - bevor er in die Architektur eingehen kann.

@stuvar:

Die Verzögerungen durch den Transport werden vernachlässigt. Das wird schon passen.

Der Zusi-Stellwerksblick hat aus meiner Sicht nur bedingt mit dem Stellwerk selbst zu tun. Das Stellwerk gibt lediglich an, wo der Blickpunkt liegen soll. Das funktioniert aber natürlich nur lokal, Zusi-Instanz am gleichen Ort. Für alles andere ist aus meiner Sicht Zusi-Multiplayerfunktionalität erforderlich.

Das Stellwerk soll nicht zusätzlich noch einen Zusi-Renderer erhalten oder?

Das Thema Verantwortungswechsel Stellwerk extern/intern ist durchaus ein berites andiskutiertes. Uns schwebt ein Umschalten im laufenden Betrieb vor, möglicherweise nur unter bestimmten Bedingungen (Transaktionsabschluss).

@Christopher:

Im Prinzip jedes Stellwerk eine eigene Instanz. Kommunikation über den Server (der irgendwie auch Sockets verwenden wird). Ausnahmen sind besagte Bahnhöfe mit B- und W-Stellwerken, wo mehrere Stellwerke zusammen eine Instanz bilden können.

[Christopher Spies]

Das Stellwerk soll nicht zusätzlich noch einen Zusi-Renderer erhalten oder?

Der war gut !

@Christopher:Im Prinzip jedes Stellwerk eine eigene Instanz. Kommunikation über den Server (der irgendwie auch Sockets verwenden wird). Ausnahmen sind besagte Bahnhöfe mit B- und W-Stellwerken, wo mehrere Stellwerke zusammen eine Instanz bilden können.

Und wie soll dann die Kommunikation zwischen vom Spieler Anwender gesteuerten Wärterstellwerk und dem vom Computer gesteuerten Befehlsstellwerk oder dem 2. Wärter ablaufen?
Werden die "unbesetzten" Stellwerke dann vom Zusi-Fahrdienstleiter übernommen oder vom Stellwerks-Simulator?

Das verstehe ich noch nicht so ganz...

- Christopher

[Roland Ziegler]

Ein Stellwerkssimulator war bisher ebensowenig vorgesehen wie ein stellwerksinterner Zusi-Renderer.

Da wäre dann in der Tat der Zusi-Fdl zuständig. Nur kennt der m.W. im Moment noch keinen Bahnhofsblock, den Carsten dann vielleicht an die Fahrstraße hängen wird, mit dem ganzen Programm, also auch Signalmelder- und Spiegelfelder-Versorgungen (letztere noch nicht im UML-Modell)

[Carsten Hölscher]

ich verfolge das Stw-Thema im Moment nur am Rande. Also ich würde jetzt warten, bis das Stw-Konzept steht und dann machen wir uns gemeinsam an die Anforderungen der Schnittstellen - ist dsa okay?

carsten

[stuvar]

Jetzt hab ich den Schritt richtig nachvollzogen. Ein Zusi das als Sichtfenster für den Stellwerker funktionieren soll. Damit müssen dann alle Züge per Autopilot fahren.
Und ich dachte wir fahren hier mit mehreren Zusi-Clients rum und können so auch mal andere Zuianer durch nocht gezogene Vorsignale nerven - wie konnt ich auch nur...

[Michael_Poschmann]

Damit müssen dann alle Züge per Autopilot fahren.

Warum denn das? Wo läge denn dann der eigentliche Zweck der Übung?

Michael

[Roland Ziegler]

Ein Zusi das als Sichtfenster für den Stellwerker funktionieren soll. Damit müssen dann alle Züge per Autopilot fahren.

Das verstehe ich auch nicht. Zusi hat doch schon jetzt die Möglichkeit, auf andere Blickpunkte zu schalten.

Die Einschränkung liegt darin, dass ohne Multiplayerfähigkeit von Zusi ein solches Stellwerksfenster das gewöhnliche Zusi-Fenster ist und man damit in der Tat den eigenen Führerstand verlässt.

Das Thema hier ist aber Stellwerk, und nicht Multiplayerfähigkeit von Zusi selbst. Eine Zusi-Instanz soll viele Stellwerksinstanzen unterstützen können. Remote-Stellwerke werden halt keinen Zusi-3D-Fensterblick haben, sondern sich mit animierten Lageplänen oder ausgeleuchteten Stelltischen begnügen müssen.

Bitte jetzt nicht erneut Grundsatzdiskussionen anfangen. Und wenn doch, dann nicht in diesem Thread.

[Christopher Spies]

Ein Stellwerkssimulator war bisher ebensowenig vorgesehen wie ein stellwerksinterner Zusi-Renderer.

Mit "Stellwerkssimulator" bezeichne ich das Programm, um dessen Architektur es hier gerade geht. Wie soll man es sonst nennen? Ich kann mich auch nicht erinnern, dafür je eine andere Bezeichnung hier gelesen zu haben.

Ist doch logisch: Neben

• "Fahrsimulator",
• "Strecken-Editor",
• "Gebäude-Editor",
• "Führerstands-Editor" und
• "Fahrzeug-Editor"

wird es in einer fernen Zukunft dann noch

• "Stellwerksimulator" und
• ggf. "Stellwerks-Editor"

geben -- oder sehe ich da etwas grundfalsch?

"Stellwerksimulator" also analog zu "Fahrsimulator" (OK, demnach müsste man es "Stellsimulator" nennen ).

- Christopher