Kommunikation

Hier geht es um die Entwicklung eines zukünftigen Stellwerks mit Zusi-Anschluss.
Nachricht
Autor
stuvar
Beiträge: 1409
Registriert: 22.07.2002 22:38:41
Wohnort: Leipzig

#21 Beitrag von stuvar »

Ich möchte auch keine Diskusion anfangen sondern habe nur noch mal die Auswirkungen rekapituliert.

Und nochmal zu meiner Behauptung: Wenn man die eine Zusi-Instanz als Sichtfenster des Stellwerkers haben möchte, dann muß man ja in Zusi den Blickpunkt verändern. Da damit der Zusi-Autopilot den gerade gefahrenen Zug übernimmt fahren alle Züge auf Autopilot. Zweck der Übung: Man hat ne Stellwerkssimu mit verbessertem betrieblichen Umfeld und 3D-Aussichtsfenster^^.

@ Roland:

Mein Vorschlag zur Beobachterfunktion war wieder viel zu früh und gehört in die Planung der Multiplayerfähigkeiten von Zusi X. Da wir aber soweit noch nicht sind ist das Thema für mich erstmal erledigt.

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#22 Beitrag von Roland Ziegler »

Ein Update aus der Forschungsabteilung über Machbarkeitsstudien:
Die Stellwerkskommunikation mit verteilten Objekten.

Schon vor einiger Zeit hatte ich mit .Net-Remoting experimentiert und dabei besonders auch die Rückrichtung im Blick: Server teilt Client ungefragt etwas mit. Das hatte soweit funktioniert.

Jüngst habe ich mich mit der Schnittstelle zwischen .Net und Win32 beschäftigt, wie ein Win32-Client Informationen an einem .Net-Server weitergibt oder asynchron per Event bekommt. Der vorgezeichnete Weg dazu geht über COM. Auch das hat nach einigen Anlaufschwierigkeiten funktioniert.

Dieser Weg, wenn man ihn einmal rausgefunden hat, ist letztlich recht straight-forward und sehr schematisch. Und wenn es dann einmal vom Prinzip her läuft, muss man sich an Anwendungsentwickler glücklicherweise auch nicht mit den Tiefen von COM beschäftigen - auf der .Net-Seite ja schon gar nicht.

Damit ist das Kommunikationskapitel aber noch nicht abgeschlossen, denn es fehlt noch das Zusammenespiel der einzelnen Schnittstellen. Ich erwarte hier durchaus noch Überraschungen, geht es doch um die Rollen der versichiedenen Threads, wer wann wo auf wen wartet, und wie sich solches Warten mit den sonstigen Aufgaben der Applikation vereinbaren lässt.

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

#23 Beitrag von Michael_Poschmann »

Roland Ziegler hat geschrieben:Ein Update aus der Forschungsabteilung über Machbarkeitsstudien:
"Muppet laboratories" ?(

Ohne fachlichen Beitrag mit Gruß an Dr. Bunse

Beaker alias Michael

Benutzeravatar
Daniel Schuhmann
Beiträge: 1147
Registriert: 21.04.2003 18:50:37
Aktuelle Projekte: Nüscht
Wohnort: Miesbach
Kontaktdaten:

#24 Beitrag von Daniel Schuhmann »

Daniel Rüscher aka Merlin hat geschrieben:Anpassen käme da wohl neuschreiben gleich. [...] 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? [...] wenn man bestimmten Stellbefehlen Prioritäten gibt um sie schneller ausführen zu können (HaGT also Signalhaltfalltaste zum Beispiel, da Sicherheitsrelevant).
Priorisieren kann er im Prinzip sogar schon (dafür gibt es das entsprechende Client-Typ-Flag im Hello-Befehl), es wurde nur bisher nicht benötigt. Und für die kommende IBIS-Funktionalität wurde der Befehlssatz bereits erweitert (die Version ist im Beta-Stadium), hier werden die Daten bidirektional gesendet und nur an bestimmte Clients gesendet. Viel anderes würde beim Stellwerk auch nicht passieren. Das ganze geschah ohne komplettes Neuprogrammieren.

Daniel
Signaturen können bis zu 50 Zeichen lang sein und

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#25 Beitrag von Roland Ziegler »

Ich hab' schon mal erwähnt, dass ich beruflich ziemlich viel mit "selbst" definierten Socket-Protokollen zu tun habe, die entweder "immer schon da" waren oder als kleinster gemeinsamer Nenner neu vereinbart wurden. Die Anwendungen darauf beinhalten meist eine Kombination aus Ereignis-Weiterleitung einerseits und Transaktions-Verhalten anderseits, verbunden mit einer mehr oder minder komplexen "Formatierung", die solche Auswüchse wie Edifact oder ASN.1 anehmen kann. Leider beschäftigt man sich die meiste Zeit nicht mit dem Protokoll selbst, sondern mit dem Versuch, die Anwendungen oben drüber auf das Protokoll zuzuschneiden. Man sehe mir nach, dass ich versuche genau das hier zu vermeiden, und statt dessen fertige, allgemein verbreitete und anerkannte Lösungen zu nutzen.

Während man asynchrones Verhalten direkt auf Sockets abbilden kann - wäre da nicht das lästige Problem der Serialisierung("Formatierung", auch Marshaling genant), ist das mit synchronem Verhalten nicht direkt möglich. Die erste diesbezügliche Erweiterung war in den späten 80er Jahren das RPC-Protokoll (von Sun). Und seither wurde hieran weiter entwickelt, eben grundsätzlich Anforderungen an Remote Communication in Layer zu packen, und vor der Anwendungsentwicklung zu kapseln.

Die Alternative, die durch Unwissen/Verdrängen/Nicht-Sehen-Wollen immer wieder gegangen wird ist, diese höheren Layer, die für Marshaling oder synchrones Verhalten erfoderlich sind, selbst zu stricken (übrigens einer der Gründe, warum auch Bottom-Up-Approaches immer wieder scheitern - weil eben das große Ganze aus dem Blick verloren geht.)

Wir sprechen hier von Neuerfindung des Rades.

Es mag ja durchaus so sein, dass die Beschäftigung mit DCE, COM/DCOM, CORBA, JAVA RMI, EJB oder .Net-Remoting am Anfang die Investition von erheblich mehr Gehirnschmalz erfordert, als ein Connect und Accept zu implementieren. Das investiert man aber doch deswegen, damit man sich später erheblich Arbeit spart.

Es steht mir fern, Daniels Socket-Nutzung irgendwie in Frage zu stellen. Ich bin mir sicher, dass diese Implementation die in sie gestellte Aufgabe erfüllt.

Nur habe ich selbst eine solchen Nutzungsprozess schon mehrfach durchlaufen und mich einmal, vor etwa 12 Jahren, auch darangesetzt, die höheren Ebenen selbst zu implementieren, aber nur deswegen, weil es auf den damals beteiligten Plattformen mangels Unterstützung durch Middleware nicht anders ging. Später, als es verfügbar war, haben wir dann einfach CORBA genommen.

Der Kern aller Remote-Object-Verfahren ist schlicht der: Man spricht mit einem Remote-Object so, als ob es lokal vorhanden ist. Die Technik dazu gibt es - sie ist alles andere als exotisch oder total abgehoben - und ich will sie auch hier nutzen.
Zuletzt geändert von Roland Ziegler am 01.07.2005 10:13:42, insgesamt 2-mal geändert.

Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

#26 Beitrag von Daniel Rüscher aka Merlin »

Kurzum, mit .net Remoting wachsen die Funktionen zu einer Anwendung zusammen. Dabei spielt es keine Rolle auf wieviele einzelne Programme oder Computer (egal wo auf der Welt) die Anwendung verteilt ist. Der User bekommt davon nicht viel mit.

@ Daniel: Das war ja auch nur ein Beispiel. Ich kenn die Internas nicht, also liegt es mir fern da irgendwas ohne Hintergrundwissen anzumotzen. Aber wie ich in meinem vorherigen Post ja geschrieben habe kann der Kommentar ignoriert werden wenn das nicht zutrifft was ich da gepostet hab.

@ Michael: Roland is n Frosch? ?( :D

Gruß Daniel
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

#27 Beitrag von Michael_Poschmann »

OT:
Daniel Rüscher aka Merlin hat geschrieben: @ Michael: Roland is n Frosch? ?( :D
Wenn wir ihn zu sehr reizen, brät er uns mit seiner Handtasche eins über die Rübe... :angst

senile Grüße aus der Läster-Loge
Michael

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#28 Beitrag von Roland Ziegler »

Neuer Bericht aus erwähnter Forschungsabteilung (8)):

Ein integrierter Demonstrator hat seinen ersten Test bestanden.

Alle drei Module spielen jetzt zusammen:
  • Der StwCommServer enthält die Kernfunktionalität. Er spielt sowohl für den Fahrsimulator als auch für das Stellwerk den Server. Zum Fahrsimulator hin (Win32) wird der StwCommServer über COM angesprochen, zum Stw hin über .Net-Remoting.
  • Der Stw-Client ist ein .Net-Remoting-Client mit zusätzlicher eingeschränkter Server-Funktionalität, denn auch der Client soll Events empfangen können. Der Stw-Client kann lokal oder irgendwo im Netz liegen. Natürlich können sich mehrere Stw-Clients zum StwCommServer verbinden.
  • Den Zusi-Client gibt es nur einmal. Es ist eine ein wenig vereinfachte :D Nachbildung des Fahrsimulators. Der Fahrsimulator ist mit dem StwCommServer über den In-Process-Server-Mechanismus von COM verbunden, der StwCommServer läuft dabei im selben Prozess wie Zusi. Zusi erzeugt im COM-Server ein Server-Objekt durch "schlichtes" CoCreate und reagiert dann auf Stellbefehle in Form von Events. Damit hat auch Zusi eine Server-Rolle.
Die gesamte Kommunikation ist selbstverständlich typsicher. Und niemand muss sich darum kümmern, wie übergebene Daten formatiert/serialisiert/gemarshaled werden müssen, um beim Empfänger lesbar anzukommen. .Net-Remoting und COM erledigen das automatisch.

Der Stw-Client verbindet sich zum allgemeinen Server-Objekt. Dazu benutzt er eine URL (ähnlich wie CORBA), z.B. so tcp://localhost:3985/StwCommServer

Code: Alles auswählen

// Registers the remote class. 
RemotingConfiguration.RegisterWellKnownClientType(
	typeof(StwCommServer.ServerProxy),
	"tcp://localhost:3985/StwCommServer");
(In Wirklichkeit steht hier natürlich kein konstanter String, sondern eine Variable.)

Der Kanal ist hier als tcp definiert - auch .Net-Remoting verwendet auf Wunsch schlichte rudimentäre Sockets - und als Marshaler wird damit defaultmäßig der binäre verwendet. Das ist am effektivsten und für unser Stellwerk sinnvoll, SOAP über http wäre es weniger.

Wenn der Verbindungsaufbau funktioniert, holt sich der Client ein Sitzungsobjekt, was nur für ihn gilt und extra erzeugt wird. Mit diesem Sitzungsobjekt bekommt er außerdem Proxy-Objekte für Weichen und Signale, und nur mit diesen Objekten wird er während der Sitzung sprechen.

Der Zugriff auf z.B. ein bestimmtes Signal sieht im Stw-Client dann so aus:

Code: Alles auswählen

private void SetSignalbild (ZusiId id, uint signalbild) {
  try {
    sitzung.Signal [id] = signalbild;
  } catch (Exception ex) {
    MessageBox.Show(ex.Message,"StwEmulator");
  }
}
Die Zugriffklasse besitzt einen Indexer, das ist eine Property mit einem Index. Der Index sei eine eindeutige ID, hier als komplexer Typ modelliert, der das Signal im Fahrsimulator identifiziert. Der Catch-Block fängt alle Ausnahmen ab, ob es eine Störung beim Netzzugriff ist, eine unzulässige ID oder ein nicht vorhandenes Signalbild eingegeben wurde. (Die Behandlung als schlichte MessageBox ist natürlich unzureichend.)

Zu Zusi hin wird aus diesem Aufruf ein COM-Event. Wie alle Win32-Sprachen tut sich Delphi mit COM-Servern schwer. Und eine Event-Senke ist ein solcher COM-Server. Da Delphi nicht über Templates verfügt, können solche Server automatisch nur über Code-Generatoren definiert werden. Da hat es glücklicherweise einen Schlaufuchs gegeben, der ein solches Tool entwickelt hat - Delphi im Auslieferungszustand muss hier anscheinend passen.

Realisiert wurde hier ein Custom-Interface, denn mit IDispatch lassen sich komplexe Parameter bei besagtem Code-Generator nicht verarbeiten - was nachvollziehbar ist. (Damit fallen VB6 oder Skript-Sprachen, die nur IDispatch können, an dieser Stelle flach, aber Carsten hat wohl auch nicht vor Zusi, in VB6 zu portieren.)

Code: Alles auswählen

function TStwZusiEmulator.OnSetSignalbild(Sender: TObject; id: ZusiId; signalbild: Cardinal): HRESULT;
begin
  Result := S_OK;
  if not signale.find(id.id) then
    Exit;

  if signalbild >= MAX_SIGNALBILD then
    signale.setZust (id.id, 0)
  else
    signale.setZust (id.id, signalbild);
    
  pStwCommServer.ReportSignalbild(id, signale.getZust (id.id));
end;
Der entscheidende Punkt hier ist, dass alle Events ohne Rückgabewert arbeiten, auch inout-Parameter gibt es nicht. Die Quittung erfolgt daher über einen expliziten Funktionsaufruf im Server. Dieses ist vielleicht nicht das Optimum an Eleganz, aber einen anderen Code-Generator gibt es nicht, oder man müsste einen vollwertigen COM-Server in Delphi entwerfen, was ich für ziemlich überflüssig halte.

(Das Objekt "signale" im Beispiel ist etwas pseudocodemäßig und soll eine mögliche Implementation nur andeuten.)

Kehrt die Funktion vorzeitig zurück (was immer sich Jensen und Wirth damals dabei gedacht haben, in Pascal kein return vorzusehen - das als Bypass von Borland angebotene Exit finde ich recht irritierend), also ohne die Report-Funktion aufzurufen, wird der Server ein Mismatch erkennen und eine Exception werfen.

Wichtig bei dem Event hier ist der synchrone Ablauf. Wenn die Report-Funktion aufgerufen wird, findet das innerhalb des Event-Handlings statt, es ist also quasi ein Callback auf den Server. Dieser synchrone Ablauf ist der ganz große Vorteil der Geschichte. Es macht die Anwendung denkbar einfach.

Achja, Threading: Im Moment ist alles Single-Threading. Das wird für weitere Versuche noch eine Weile genügen.
Zuletzt geändert von Roland Ziegler am 03.07.2005 17:58:15, insgesamt 1-mal geändert.

Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

#29 Beitrag von Daniel Rüscher aka Merlin »

Hallo Roland,

Das ist ja nur ein Test, aber mir ist eins aufgefallen: Wenn wir die Umsetzung schon in Zusi 2 anpeilen sollten wir StwComm in beide richtung mit .net Remoting auszustatten und die Kommunikation mit Zusi über ein kleines Helper Programm zu umsetzen, das die Umsetzung .net <-> Com macht.
Hat folgenden Hintergrund: Zusi3 ist ja (wenn ich es richtig mitbekommen habe) in .net Programmiert. Also dann auch .net Remoting. Wenn nun von Zusi2 auf Zusi3 ansteht lässt man einfach das HelperProgramm weg, und braucht den eigentlichen SourceCode von StwCom nicht anfassen.

Das war nur mal so n Gedanke der mir durch den Kopf geschossen ist. Wenns Blödsinn ist bitte Post ignorieren.

Gruß Daniel
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#30 Beitrag von Roland Ziegler »

Kleines Missverständnis. Der Fahrsimulator bleibt laut Carsten auch in Zusi 3 Win32 (man bedenke, dass dort Performance ein ganz erhebliches Kriterium ist.) Von daher ist das Konzept meines Demonstrators schon sehr auf die tatsächliche Umgebung zugeschnitten.

Allerdings ist es so, dass man den "Zusi"-COM-Win32-Client ohne eine einzige Zeile Code zu ändern durch einen .Net-Client ersetzen kann. So mache ich das bei mir im Moment auch, wenn ich den Server interaktiv debuggen will.

Wie schon geschrieben ist der Event-Mechanismus, der dem "Zusi"-Client eine explizite Anwort abfordert, nicht das Optimum an Eleganz. Für den Stw-Client, der an keine COM-Restriktionen gebunden ist, werde ich noch mit echten Callback-Objekten experimentieren, aber das geht in COM so nicht, wollte man nicht die Client-Anwendung wesentlich umstricken. Der jetzige COM-Client ist "light", d.h die Anwendung wird wegen der Server-Anbindung nicht umgestrickt.

Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

#31 Beitrag von Daniel Rüscher aka Merlin »

Wunsch zwar blödsinn, aber schon umgesetzt... Na das is doch mal was.
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#32 Beitrag von Roland Ziegler »

Was ich Euch gestern abend noch vorenthalten habe, war das Handling im Server. Das trage ich hier jetzt nach, für das Signal-Beispiel:

Code: Alles auswählen

  // Typedefinition der Events für Zusi-Client
  public delegate void SetSignalbildDelegate(ZusiId id, uint signalbild);
  public delegate void GetSignalbildDelegate(ZusiId id);

  // Server-Signal-Handling
  public class SignalImpl : SignalProxy {
    // rückgemeldete ID für aktuellen Call 
    private ZusiId m_id;

    // rückgemeldeter Ist-Zustand für aktuellen Call
    private uint m_signalbild;

    //-----------------------------

    // Anfragen an Zusi Client per Event
    public event SetSignalbildDelegate OnSetSignalbild;
    public event GetSignalbildDelegate OnGetSignalbild;
    //-----------------------------

    // Rückmeldung von Zusi-Client
    public void Acknowledge (ZusiId id, uint signalbild) {
      m_id = id;
      m_signalbild = signalbild;
    }
    //-----------------------------
    // Indexer, Aufruf durch Stw-Client
    public override uint this [ZusiId id] {
      set {
        if (id.isNull())
          throw new StwException (StwException.ESubtype.IdFehler);

        m_id.Clear (); // wird durch Rückmeldung geändert
        
        // Event-Aufruf, synchron bis zur Senke
        OnSetSignalbild (id, value); 
        // Rückmeldung via Acknowledge() erwartet innerhalb des Event-Calls.

        // Ergebnis prüfen
        if (id != m_id)
          throw new StwException (id, m_id);
        if (m_signalbild != value)
          throw new StwException (value, m_signalbild);
      }
      get {
        if (id.isNull())
          throw new StwException (StwException.ESubtype.IdFehler);

        m_id.Clear ();
        
        // Event-Aufruf, synchron bis zur Senke
        OnGetSignalbild (id);
        // Rückmeldung via Acknowledge() erwartet innerhalb des Event-Calls.

        // Ergebnis prüfen
        if (id != m_id)
          throw new StwException (id, m_id);
        return m_signalbild;
      }
    }
  }

Betrachten wir den Setter. Im Aufruf von Set steckt sowohl die ID als auch der Wert. Mit beiden Parametern wird der zugehörige Event ausgelöst. Ist der Zusi-Client nun angemeldet, wird er den Event empfangen und quittieren. Die Quittung erfolgt über die Methode Acknowledge(). Die geschieht innerhalb des Event-Aufrufs durch Callback. Danach enthalten die beiden Member-Felder die rückmeldete ID und den rückgemeldeten Zustand. Passt was nicht, gibt's 'ne Exception, die natürlich beim Aufrufer des Setters auch mit allen inhaltlichen Details ankommt.


Zumindest ich halte die hier dargestellte Lösung für deutlich einfacher und flexiber als eine wie auch immer geartete Zu-Fuß-Implementation eines zugeschnittenene Protokolls auf Socket-Basis.


Man kann das mit den Remote-Objects übrigens beliebig weit treiben. Ich habe jetzt mal auch auf Stw-Client-Seite einen ausgeprägten Empfänger eingebaut, eine Klasse, die zwar momentan nur eine Ping-Methode hat, aber eben nicht nur einen Event bzw dessen Handler darstellt. Ein auf Stw-Client-Seite residierendes Objekt dieser Klasse wird bei der Anmeldung am Server mit übergeben, und erhält dann Sitzungs-Stayalive-Pings. Werden die nicht beantwortet, wird die Sitzung getrennt.

Das tolle an .Net-Remoting ist, dass man fast beliebige Objekte so zwischen den beiden Prozessen/Rechnern hin- und herschieben kann (geht meist per Referenz, natürlich), wenn die erste Verbindung zu einem Objekt einmal steht - so eine Art Bootstrapping. Das geht zwar in CORBA auch, muss aber immer vorher in IDL definiert worden sein.

.Net-Remoting kommt ohne IDL aus. Die Schnittstelle muss aber trotzdem definiert werden. Wie ist Sache des Anwenders. Sinnvoll ist eine kleine gemeinsame Assembly, die eine ähnliche Aufgabe wie IDL übernimmt, nämlich die Interfaces zu definieren. Allerdings müssen diese Interfaces hier instanzierbare Klassen sein, denn es werden auf beiden Seiten Objekte dieser Klasse tatsächlich erzeugt. Zusätzlich kann und wird der jeweilige Server durchaus von der Basisklasse ableiten, um dann die "richtige" Funktionalität zu implementieren.

Durch Konzentration aller am Remoting beteiligten Klassen in eine eigene Assembly und durch Beschränkung der Klassendefinition auf die von Basisklassen wird eine gute Entkopplung zwischen Client- und Server erreicht, so wie bei expliziter Verwendung einer IDL. Client und Server können weiter entwickelt werden, ohne voneinander wissen zu müssen.
Zuletzt geändert von Roland Ziegler am 04.07.2005 22:41:43, insgesamt 1-mal geändert.

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

#33 Beitrag von Michael_Poschmann »

Roland Ziegler hat geschrieben:Ein auf Stw-Client-Seite residierendes Objekt dieser Klasse wird bei der Anmeldung am Server mit übergeben, und erhält dann Sitzungs-Stayalive-Pings.
...die der Stellwerker natürlich auch manuell auslösen könnte. -> Demnächst auf den ESTW: Die "Ziegler-Taste", auch als "Sifa der Stellwerke" in der Fachwelt ein Begriff.

:mua Mit Ideen für Anwendungen, die die Welt nicht benötigt
grüßt
Michael

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#34 Beitrag von Roland Ziegler »

... wobei in der Zusi-Variante das nicht regierende Stellwerk keiner Zwangsbremsing unterzogen, sondern ihm schlicht die Kompetenz entzogen wird und seine Aufgaben einfach wieder an den Fahrsimulator zurückfallen. :]

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

#35 Beitrag von Michael_Poschmann »

Roland Ziegler hat geschrieben:... wobei in der Zusi-Variante das nicht regierende Stellwerk keiner Zwangsbremsing unterzogen, sondern ihm schlicht die Kompetenz entzogen wird und seine Aufgaben einfach wieder an den Fahrsimulator zurückfallen. :]
Hauptsache fail-safe, ganz im Gedenken an die Fremo-Veranstaltung in Heinsberg vor zwei Jahren.

Gruß
Michael

Benutzeravatar
Oliver Lamm
Beiträge: 3102
Registriert: 04.01.2002 15:02:17
Aktuelle Projekte: Aachen - Neuss für Zusi3
Wohnort: Essen
Kontaktdaten:

#36 Beitrag von Oliver Lamm »

Zwangsbremsing
Immer dieses Neudeutsch,

Grütings, Oli :D
Oliver Lamm
mail(AT)oliverlamm(DOT)de

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#37 Beitrag von Roland Ziegler »

Thread wieder nach oben holend:

Mein Kommunikationsansatz nutzt ja derzeit .Net Remoting. Das war vor einem Jahr auch Stand der Technik, und bietet all das, was für unsere Anwendungsfälle erforderlich ist: Connection oriented, stateful, Marshal-byReference und Marshal-By-Value, Callback, Event-Disptching, Exception-Handling, effektives Binär-Protokoll. Die vor einem Jahr theoretische andere moderne Alternative, nämlich XML-Web-Services, war viel zu eingeschränkt, und kam nach kurzer Analyse gar nicht mehr in die nähere Auswahl.

Inzwischen lugt Vista (Longhorn) um die Ecke, und damit .Net 3.0 (WinFx). Dazu gehören nun die Windows Connection Services (WCF, vormals Indigo).

Im Frühjahr schien es noch so, als ob WCF eigentlich eine neue, etwas erweiterte Ausgabe für XML Web Services sein würde, jetzt mit Datenbanktransaktionsmonitor und weiteren, in höchstem Grade für unsere Zwecke uninteressanten Features, aber gleichzeitig mit dem Wegfall wesentlicher und bisher von mir genutzter Eigenschaften von .Net Remoting (s.o.).

Als bekannt wurde, dass .Net Remoting nicht mehr weiterentwickelt würde, führte das übrigens zu Unmutsäußerungen der Anwender, wären doch "primitive" Web-Services kein Ersatz für die vielfach genutzten erweiterten Möglichkeiten von Remoting. Möglicherweise ein Missverständnis. Inzwischen liest man häufiger von doch erheblich mehr Funktionalität bei WCF und es scheint vorstellbar, dass das meiste aus Remoting übernommen worden sein könnte, wenn auch etwas versteckt, weil für Web-Service-Schreiber ohne Bedeutung (HTTP ist dabei eine der großen Einschränkungen).

Damit stellt sich durchaus die Frage, wie wir es mit der internen Stellwerksschnittstelle handhaben werden. Noch ist das ein Thema von morgen, und nicht heute zu entscheiden. Ich könnte mir aber durchaus vorstellen, auf WCF zu setzen, wenn sich die Funktionalität als gleichwertig zu .Remoting herausstellen würde. Abstriche würde ich nicht hinnehmen wollen, denn dann müsste man ja wieder selber ran.

.Net 3.0 soll übrigens neben Vista auf auf XP SP2 und W2k3 laufen. Aber nicht mehr auf W2k.

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

#38 Beitrag von Michael_Poschmann »

Roland Ziegler hat geschrieben:.Net 3.0 soll übrigens neben Vista auf auf XP SP2 und W2k3 laufen. Aber nicht mehr auf W2k.
Wieviele Zusianer verlieren wir denn dann auf diese Weise?

?( Michael

Benutzeravatar
Christoph Blümer
Beiträge: 1441
Registriert: 18.02.2003 19:47:39
Wohnort: Waiblingen (b. Stuttgart)

#39 Beitrag von Christoph Blümer »

Roland Ziegler hat geschrieben:.Net 3.0 soll übrigens neben Vista auf auf XP SP2 und W2k3 laufen. Aber nicht mehr auf W2k.
Ich schließe mich da Michaels Zweifeln an. Da XP leider keine Win2000 vergleichbar bequeme Rechteabstufung besitzt, verspüre ich wenig Lust, darauf umzusteigen. Zum Thema Vista: über ungelegte Eier gackert es sich gut, und vor ServicePack 1 ist das wie bei Windows bisher üblich sowieso völlig unbrauchbar... :rolleyes:

Christoph

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#40 Beitrag von Roland Ziegler »

Ich möchte bei diesem Thema etwas über das Heute und Jetzt hinaussehen. Eine solche Schnittstelle kann ja durchaus ein längeres Leben haben, als sämtliche Anwendungen, die darauf aufsetzen.

Von der Konfiguaration her hätte WCF nämlich immense Vorteile. Dies ist bei .Net Remoting recht hausbacken.

Wenn ich im Konjunktiv geschrieben habe, was die Funktionalität von .Net 3.0 angeht, dann nur deswegen, weil ich selbst keine Zeit dazu finde, in das SDK heineinzuschauen. Denn die Entwicklungsumgebung ist als Final Beta / Release Candidate oder so ähnlich seit Frühjahr verfügbar. In diversen Fachzeitschriften standen auch schon Übersichten und Beispiele. Ingo Rammer, einer der MS .Remoting-Gurus, schreibt Praxisartikel in seinem Blog.

Der Bruch mit Vista wird eh ziemlich groß werden, da sollten wir uns nichts vormachen. Der Sprung wird fast so groß wie damals von 16bit-Windows auf NT (lassen wir die 95er Schiene mal außen vor). Es steht nicht weniger auf dem Programm als die Ablösung von Win32 (das ist das Windows API). Natürlich besteht ein deutlicher Wahrnehmungs-Unterschied. Der damalige Sprung war für MS und seine Kunden der aus der Amateur- in die Profi-Liga. Anders heute: Endnutzer, und da stimme ich zu, werden in Vista außer ein paar lustigen Spielereien zunächst überhaupt keine Vorteile sehen. Entwickler aber begegnen neuen Paradigmen, aus die sie lange gewartet haben. Und das wird sich vermutlich recht schnell auf die Anwender-Software auswirken. Auch mir machen diese Aussichten nicht nur Freude. Wer lernt schon gerne um, selbst wenn man sich über altbackende Paradigmen immer wieder ärgert.

Ich schrieb schon, die Entscheidung muss nicht kurzfristig fallen. Natürlich mache ich zunächst weiter mit .Remoting, werde mir aber schon gelegentlich anschauen, wie das in dem Nachfolge-Framework aussieht.

Ich stehe häufiger vor solchen Fragen. Eine reine Funktionalitätsfrage war es in diesem Beispiel aus jüngster TransDEM-Zeit und der WMS-Anbindung: Im Win32-SDK gibt es mehrere Bibilotheken für Internet-Verbindungen. Zwei können HTTP. Die eine, ältere, läuft auf fast allen Systemen von 98 bis W2k. Die neuere nur noch auf XP und W2K3, auf W2K nur mit Einschränkungen. Die neuere aber kann SSL (das ist die Veschlüsselung für HTTPS) out of the box. Meine Entscheidung war jetzt noch einmal gegen die neuere Bibliothek, was ich hoffentlich nicht bereuen muss, denn TransDEM WMS kann eben nun kein HTTPS. Denn dieses "Zu Fuß" irgendwie einzubinden, dafür war mir mir dann die Zeit zu schade, wenn man das auch mit einem einzigen Funktionsaufruf haben kann.

@Christoph: XP kennt doch sämtliche Feinabstufungen der Rechte wie W2k. Die sind an der Stelle doch absolut kompatibel.

Antworten