http://der-moba.de/api.php?action=feedcontributions&user=Stefan+Bormann&feedformat=atomDerMoba - Benutzerbeiträge [de]2024-03-29T13:52:59ZBenutzerbeiträgeMediaWiki 1.25.1http://der-moba.de/index.php?title=SRCP-Erweiterungen&diff=11959SRCP-Erweiterungen2007-02-25T10:10:05Z<p>Stefan Bormann: SBor hat sich hinzugefuegt</p>
<hr />
<div>==Das initiale Posting==<br />
<br />
Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.<br />
<br />
Hier der initiale Eintrag:<br />
<br />
Hallo SRCP-Fans!<br />
<br />
ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich<br />
aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das<br />
mein erster Eintrag in der Gruppe ;).<br />
Während der Entwicklung kamen einige Ideen, die ich nun hier zur<br />
Diskussion stellen möchte:<br />
<br />
# Ich hätte gern einen Dienst für Clients, mit dem sie den Server (bzw. dessen IP-Adresse) finden können. Da gibt es sicher mehrere Möglichkeiten, ich dachte an Broadcast oder an eine DHCP-Option.<br />
# Stichwort CRCF: Was ist mit der Entwicklung? Ich hätte gern dieses Feature für SRCP und würde mich ggf. an der Mitentwicklung beteiligen.<br />
<br />
Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art<br />
Stammtisch?<br />
<br />
Gruß, Sven.<br />
<br />
Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.<br />
<br />
<br />
==SRCP-Stammtisch==<br />
Um die aktuellen Vorhaben besser diskutieren zu können, schlage ich ein Treffen in Form eines Stammtisches vor. Vielleicht kann man sich hier zunächst über einen Ort des Treffens verständigen, der von den meisten gut erreichbar ist.<br />
<br />
{| border=1 align="center" width="50%"<br />
|+ <br />
! SRCP-Interessierter<br />
! Wohnort<br />
<br />
|-<br />
| Sven Schlender<br />
| Karlsruhe<br />
<br />
|-<br />
| Stefan Bormann<br />
| Bremen<br />
<br />
|-<br />
| ...<br />
| ...<br />
|}<br />
<br />
==SRCP-Server-Suchdienst==<br />
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ Zeroconf]-Systemdienst (DNS-SD/mDNS) einzusetzen. Dieser ermöglicht die Suche bzw. das Veröffentlichen beliebiger Systemdiente durch das Versenden eines ServiceDiscovery-Multicasts. Es existieren hierfür derzeit zwei zueinander kompatible Implementierungen, die beide als OpenSource freigegeben sind:<br />
<br />
* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.<br />
* [http://avahi.org/ Avahi], als praktisch schon etablierter Standard für Linux.<br />
<br />
Unter anderem ist es hiermit möglich, Angaben über die Portnummer zu veröffentlichen, auf der der Server seinen Dienst anbietet. Obgleich es für das SRCP-Protokoll mittlerweile eine offiziell über [http://www.iana.org/ IANA/IETF] reservierte Portnummer (4303) und Protokollbezeichner (srcp) gibt, hat ein SRCP-Administrator problemlos die Freiheit, einen von der aktuellen SRCP-Spezifikation abweichenden Wert für die Portnummer zu wählen. Auch die Anzahl der in einem Netz betriebenen SRCP-Server ist damit nicht eingeschränkt.<br />
<br />
Dem Administrator eines SRCP-Servers bleibt es überlassen, auf dem gleichen Rechner auch einen „Zeroconf“-Systemdienst einzurichten. Er muß, wenn er auf seiner Modellbahn entsprechende SRCP-Clients benutzen möchte, das Programm installieren und so konfigurieren, dass der SRCP-Dienst veröffentlicht wird. Alternativ kann ein SRCP-Server sich auch automatisiert beim Zeroconf-Dienst anmelden. Die eigentliche Arbeit für die Nutzung des SD-Dienstes liegt beim Entwickler des „Einsteck-und-Spiel“-SRCP-Clients, denn dieser SRCP-Client muß nicht nur SRCP sprechen, sondern auch noch ein DNS-SD/mDNS-Client sein.<br />
<br />
Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service<br />
(Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.<br />
<br />
<service-group><br />
<name replace-wildcards="yes">srcpd on %h</name><br />
<service protocol="any"><br />
<type>_srcp._tcp</type><br />
<host-name>srcp.example.com</host-name><br />
<port>12345</port><br />
<txt-record>SRCP auf Mobaserver</txt-record><br />
</service><br />
</service-group><br />
<br />
==CRCF-Erweiterungen==<br />
<br />
Obwohl CRCF (Common Railroad Configuration Files) vor einigen Jahren einmal vorgeschlagen wurde, wurde es nicht angenommen, da es möglicherweise zu wenig Interessenten fand. Umso mehr Interessenten fanden sich nun in dieser Diskussion. Das deutet darauf hin, dass CRCF weiterhin ein Thema ist. Über die Idee von CRCF hinaus gab es einige weitgehendere Ideen dazu.<br />
<br />
<br />
===Anforderungen an CRCF===<br />
<br />
* Umständlich Eingabe von Informationen über Loks und Zubehör soll entfallen<br />
* Anlagenweite Anzeige von Klartextnamen anstatt von Adressen<br />
* Im Bezug auf den Server-Suchdienst könnte CRCF die Hostnamen (IP-Adressen) der SRCP-Server verwalten<br />
* Verwaltung statischer Informationen<br />
* Verwaltung dynamischer Informationen<br />
* CRCF in ausdruckbarer Form<br />
* Gliederung der CRCF<br />
* SRCP-Server sollten Zugriff auf die CRCF erhalten<br />
* Kommunikation zwischen Clients<br />
<br />
<br />
===Fragestellungen===<br />
<br />
* Wo soll die CRCF liegen?<br />
* Wie soll der Auskunftsdienst aussehen?<br />
* Wie sollen dynamische Informationen von der CRCF verwaltet werden?<br />
* Betrifft die Kommunikation zwischen Clients die CRCF?<br />
<br />
Folgendes Schema sollte als Grundlage für weitere Diskussionen dienen:<br />
<br />
(TODO: Abbildung)<br />
<br />
<br />
===Implementierungsvorschläge===<br />
<br />
====Datenablage gemäß CRCF Spezifikation 0.2.0====<br />
* basiert auf SRCP<br />
* physikalisch liegen die CRCF-Daten beim SRCP-Server<br />
* Auskunftdienst ist Bestandteil von SRCP (Befehl CONFGET)<br />
* ist praktisch auf SRCP 0.7.1 ausgerichtet, deswegen fehlen wichtige Details der 0.8.X-Welt, wie z.B. Busse<br />
* unterstützt die CRCF als textbasierte Dateien<br />
* Verwaltung der Daten in Sinne von SRCP -> d.h. Die einzelnen Datenfelder kommen aus der SRCP-Welt<br />
* hält ausschliesslich statische Daten bereit<br />
* enthält auch Daten über die Eigenschaften eines Servers<br />
* pro SRCP-Server eine CRCF<br />
<br />
====Datenablage bei einem spezialisierten SRCP-Client====<br />
* die CRCF-Daten liegen bei einem SRCP-Client<br />
* Anfragen an die CRCF erfolgen zunächst an den SRCP-Server, der die Daten an den spezialisierten Client weiterleitet<br />
* nutzt SRCP als Tunnel, da CRCF-Anfragen nur weitergeleitet werden<br />
* Auskunftsbefehl ist jedoch als SRCP-Kommando auszuführen<br />
* Durch das ungesehene Weiterleiten von Nachrichten durch den SRCP-Server wird eine Kommunikation zwischen Clients ermöglicht <br />
* der Client muss sich bei allen verfügbaren SRCP-Server anmelden, damit Daten anlagenweit verteilt werden können<br />
* Der Client kann dann konsistent statische und dynamische Daten verwalten<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* Verwaltung von Daten, die über die SRCP-Welt hinausgehen, beispielsweise die Verwaltung von Fahrstrassen und kompletten Layouts<br />
<br />
====Datenablage bei einem separaten CRCF-Server====<br />
* Auskunftsdienst muss als neues Protokoll implementiert werden<br />
* SRCP-Clients sowie SRCP-Server können anfragen<br />
* Verwaltung von rein statischen Daten<br />
* Falls zusätzlich zum Auskunftsdienst ein Meldedienst implementiert wird, können auch dynamische Daten verwaltet werden<br />
* Kommunikation zwischen Clients könnte mittels einer Mailboxfunktion möglich werden<br />
* das SRCP-Protokoll wird nicht geändert, CRCF existiert parallel<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* SRCP-Server können Meldungen an die CRCF senden, um deren Inhalt zu aktualisieren<br />
<br />
====Bereitstellung der CRCF-Daten via Zeroconf-Dienst====<br />
<br />
* ...<br />
<br />
===Erweiterung des bisherigen Befehlsvorrats===<br />
Der bisherige Namensraum von CRCF umfaßt keine Befehle, die Objekte einer höheren Abstraktionsebene beschreiben. Für die Attribute dieser makroskopischen Objekte gibt es ebenfalls noch keine Festlegung. Zum Teil sind die Werte dieser Attribute statisch zum Teil ändern sich sich während des Betriebs. Der Bedarf für folgende Begriffe ist vorhanden:<br />
<br />
; Stellwerk (RWCC, Railway Control Center)<br />
:: Steuerungsinstanz, die Fahrstraßen verwaltet, für ein oder mehrere Bahnhöfe zuständig ist, Zugmeldungen abwickelt, ihr zuständiges Streckennetz kennt, einzuhaltende Geschwindigkeiten überwacht und bei Überschreitungen eingreift etc.<br />
; Gleisbild (LAYOUT)<br />
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, etc.<br />
; Fahrstraße (ROUTE)<br />
:: Sicherheitstechnisch überwachter Streckenabschnitt innerhalb eines Stellwerks, der über Informationen zur Start- und Zielsignal, Soll-Weichenstellungen, Freimeldeabschnitte, Typinformation (für anzuwendenden Regelsatz), den aktuellen Zustand (eingestellt, aufgelöst, reserviert, teilaufgelöst) etc. verfügt.<br />
; Weichenstraße (?)<br />
:: Sammlung schaltbarer Magnetartikel und ihrer Sollstellungen ohne sicherheitstechnische Überwachung <br />
:: Anmerkung von svesch: Das ist meiner Meinung nach kein neues Objekt, das ist nur eine Liste von GAs.<br />
; Zugsteuerung (TNCC, Train Control Center)<br />
:: Instanz, die die Logistik eines gegebenen Vorrats an Zügen übernimmt z.B. fahrplangesteuerte Fahrten von Zügen zwischen Bahnhöfen<br />
; Zug (TRAIN)<br />
:: Instanz, die über ihre Zugnummer identifizierbar ist, eine oder mehrere Lokomotiven ansteuert, Informationen zu Typ und Länge verfügt etc.<br />
<br />
(TODO: weitere ergänzen)<br />
<br />
==SRCP-Erweiterungen==<br />
Der bisherige Umfang des SRCP-Protokolls definiert keine Möglichkeit, mit der SRCP-Clients untereinander direkt Informationen austauschen können. Ein Bedarf dafür ist jedoch durchaus gegeben, wie folgende Auflistung zeigt:<br />
<br />
* Zugmeldungen zwischen Stellwerken<br />
* Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)<br />
* Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung<br />
* Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware<br />
* Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz<br />
* Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation (FIXME: falsch einsortiert)<br />
<br />
Weiterhin ist es mit SRCP prinzipiell möglich, eine Modellbahnanlage über mehrere SRCP-Server zu bedienen, es gibt aber bisher kein Konzept, das einen Informationsübergang zwischen den Server-Bereichen erlaubt.<br />
<br />
Zur Realisierung dieser neu zu implementierenden Informationswege wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.<br />
<br />
<br />
===Neuer Befehl im Kommandomodus===<br />
====Bewertung des Vorschlags====<br />
<br />
Die Implementierung wird nicht weiterverfolgt, da der Vorschlag zur neuen Gerätegruppe besser ins bisherige SRCP paßt. Die hier andiskutierten CRCF-Nachrichten können mit dem anderen Vorschlag ebenfalls transportiert werden.<br />
<br />
====Vorschlag====<br />
Die aktuell SRCP-Spezifikation umfaßt für den Kommandomodus einen definierten Satz an Befehlen, die in der folgenden allgemeinen Syntax an den Server gesendet werden:<br />
<br />
<kommando> <kommandoparameter> <br />
<br />
Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:<br />
<br />
<kommando> <bus> <gerätegruppe> <parameter><br />
<br />
Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.<br />
<br />
Vom Server abgearbeitete Befehle werden an alle im Infomodus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ mit der folgenden allgemeinen Syntax weitergeleitet:<br />
<br />
<codenr> INFO <bus> <gerätegruppe> <parameter><br />
<br />
Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.<br />
<br />
Von dieser Situation ausgehend, kann ein neues Kommando ergänzt werden, dass von SRCP-Server selbst nur zum Weiterleiten einer Nachricht an die angeschlossenen SRCP-Clients genutzt wird. Den Inhalt der Nachricht muß der SRCP-Server nicht interpretieren. Die Form der Nachricht kann/soll/muß den gängigen SRCP-Konventionen bezüglich Zeichensatz, Länge etc. genügen.<br />
<br />
Ein erster (anarchischer) Ansatz könte in SRCP 0.8-Terminologie so aussehen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
ECHO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 ECHO <message><br />
<br />
Einzweiter, mehr geordneter Ansatz, schreibt die Verwendung definierter Befehle (SRCP-Makros) vor, analog also beispielsweise so:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
MACRO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 MACRO <message><br />
<br />
Wobei <message> diesmal eine Folge von definierten (genormten) Befehlen inklusive deren Wert-Parametern sein muß. Diese Makros müssen natürlich den Kommunikationsbedarf der Clients (Frage/Antwort-Spiele) abdecken.<br />
<br />
Der dritte Ansatz wäre, statt der neu zu erfindenden Makros, CRCF zu benutzen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
CRCF 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 CRCF <message><br />
<br />
Der Inhalt von <message> wäre dann eine CRCF-Befehlsfolge.<br />
<br />
Angenommen eine Ablaufsteuerung (als eigener SRCP-Client) möchte eine Fahrstraße einstellen, dann sendet er an das zuständige Stellwerk folgende (CRCF-)Befehlsfolge:<br />
<br />
ROUTE <routeid> SET STATE 1<br />
<br />
Den Erfolg bekommt er dann vom Stellwerk zurückgemeldet oder kann ihn auch abfragen z.B. gemäß:<br />
<br />
ROUTE <routeid> GET STATE<br />
<br />
Den Bedarf, dass ein SRCP-Client einem Stellwerk Daten zur Konfiguration von Fahrstraßen sendet, wäre prinzipiell auch möglich:<br />
<br />
ROUTE <routeid> ADD GA <busid> <address> <port> <state><br />
<br />
Oder entfernen:<br />
<br />
ROUTE <routeid> REMOVE GA <busid> <address><br />
<br />
Um eine Client-Client-Verbindung zu unterhalten, müßte der Sender eines CRCF-Befehls seine<br />
SRCP-Session-ID immer mitsenden, dann könnte die Antwort zielgerichtet erfolgen:<br />
<br />
CRCF 0 <sender-sessionid> <empfänger-sessionid> <CRCF-message><br />
<br />
Mit dem Inhalt von <sessionid> ließe sich ein CRCF-Broadcast einfach von einer Punkt-zu-Punkt-Verbindung unterscheiden:<br />
<br />
# Der Wert ist 0: Broadcast<br />
# Der Wert ist >0: Punkt-zu-Punkt-Verbindung<br />
<br />
Auch das Thema "Zugbeeinflussung" läßt sich hiermit darstellen. Ein Zug muß während seiner Fahrt Geschwindigkeitsregeln einhalten, die das Stellwerk überwacht. Bei Überschreitungen sendet das Stellwerk einen Abbremsbefehl:<br />
<br />
CRCF 0 <sender-session-id> 0 TRAIN <train-id> SPEED SET 0<br />
<br />
===Neuer Sitzungstyp===<br />
<br />
====Bewertung====<br />
<br />
Die Diskussion dauert noch an, daher ist keine abschliessende Bewertung möglich<br />
<br />
====Vorschlagstext====<br />
<br />
Die Implementationen von CRCF bzw. Generic Messages und den bisher definierten SRCP-Sitzungen werden komplett getrennt.<br />
<br />
Motivation:<br />
* Ermöglicht Kapselung von unterschiedlichen Client-Funktionalitäten: die bestehenden Sitzungen und Generic Messages sind für komplett unterschiedliche Zwecke gedacht. Die bisherigen Steuerungs-Sitzungen dienen der Kommunikation mit der Modellbahn-Hardware, Generic Messages dienen der Kommunikation der Clients untereinander.<br />
* Dies senkt die Anforderungen an einen reinen Steuerungs-Server, er muss Generic Messages nicht unterstützen. ''Anmerkung von svesch: Der Server muss die GMs nur weiterleiten. CRCF macht nur Sinn, wenn es die SRCP-Server auch wirklich unterstützen. Sozusagen mandatory ab Version X.''<br />
* Es erspart mobilen Eingabegeräten z.B. einem Handregler den extremen Traffic, den intelligentere stationäre Clients untereinander haben. ''Anmerkung von svesch: Das ist ein wichtiger Punkt, den habe ich im Punkt "Vorschläge zur Trafficminimierung" versucht Rechnung zu tragen.''<br />
<br />
Bei der Einschätzung des Programmieraufwands gehen die Meinungen auseinander. Die einen sehen Zusatzaufwand in der dritten TCP-Verbindung, andererseits erhöht die Kapselung der Funktionalitäten die Wartbarkeit des Systems.<br />
<br />
Eigene Sitzungen trennen sowohl den Namensraum für Steuerung und Generic Messages als auch den durch beide Kommunikationsformen entstehenden Netzwerkverkehr:<br />
<br />
SET PROTOCOL GM 0.3<br />
SET CONNECTIONMODE GM INFO|COMMAND<br />
<br />
Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig. Alternativ ist ein Systemdienst möglich, der nur GM-Sitzungen, aber keine Steuerungs-Sitzungen unterstütz.<br />
<br />
===Neue Gerätegruppe===<br />
<br />
====Bewertung====<br />
<br />
Allgemein nutzbare Kommunikationsstrecke. SRCP muß um einige<br />
Details erweitert werden (siehe unten). Es entsteht ein permanenter<br />
Pflegedienst für Vergabe der Messagetypen (kann automatisiert werden)<br />
<br />
====Vorschlagstext====<br />
<br />
Für den generalisierten Messageaustausch wird eine neue Devicegruppe <br />
auf Bus 0 eingerichtet:<br />
<br />
GM Generic Message<br />
<br />
Die einzige (sinnvoll) anzuwendende Methode ist SET.<br />
<br />
Im Kommandomodus:<br />
<br />
SET 0 GM <AntwortID> <EmpfängerID> <messagetype> <messagetext><br />
<br />
EmpfängerID ist SessionID, die die Message<br />
erhalten soll. Ist diese 0, so wird die Message als Broadcast an<br />
alle INFO Sessions gesendet. Die AntwortID ist die SessionID (oder<br />
0) der INFO Session, an die eine evt. Antwortmessage gesendet<br />
werden soll.<br />
''Anmerkung von svesch: Die Session IDs übernehmen eine zentrale Rolle bei GM. Was meiner Meinung auch in der aktuellen SRCP-Spec fehlt, ist die Beschränkung der ID auf einen Wertebereich. Vorschlag: 32 Bit oder, da es sich um Klartextnachrichten handelt, 9 Zeichen. Warum muss der Client bei "SET 0 GM"-Anfragen seine AntwortID mitsenden? Der Server könnte diese ID in die INFO-Nachricht eintragen, er kennt sie ja.''<br />
<br />
Im INFO Modus:<br />
<br />
INFO 0 GM <AntwortID> <EmpfängerID> <messagetype> <messagetext><br />
<br />
Für <messagetext> gilt die im SRCP übliche Einschränkungen/Formatanforderungen<br />
dass die Zeilenlänge auf 1000 Zeichen begrenzt ist und der Zeichensatz aus 7bit <br />
ASCII besteht.<br />
<br />
<messagetype> ist ein zentral (WO??) gepflegte (VON WEM?) Liste von Identifiern <br />
um den Messagetyp erkennen zu können.<br />
<br />
Beispiel: Ein Client fragt nach den Einzelheiten des Gerätes GA 1 auf<br />
Bus 17. (Schritt A) Antwort an SessionID 45 erbeten.<br />
<br />
SET 0 GM 45 0 CRCF CONFGET 17 GA 1<br />
<br />
Wie der INFO aussieht, dürfte offensichtlich sein. Er geht an alle INFO Sessions.<br />
(Schritt B)<br />
<br />
INFO 0 GM 45 0 CRCF CONFGET 17 GA 1<br />
<br />
<br />
Wenn ein CRCF Service diese Message erhalten hat, sendet er eine<br />
passende Antwort an den SRCP Server (Schritt C)<br />
<br />
SET 0 GM 25 45 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Die Infosession des CRCF Services ist im Beispiel 25, die Antwort wird vom<br />
SRCP Server direkt an die SESSION 45 weitergeleitet.<br />
<br />
INFO 0 GM 25 45 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Der Nachrichtenfluß ist im Bild dargestellt. CA ist die Command Session von<br />
Client A, IA die Infosession. Client B (CRCF Server analog).<br />
<br />
Weitere Anfragen kann der Client direkt an Session 25 stellen. Er erhält<br />
die Info sofort, wenn Session 25 terminieren sollte. Dann kann er wieder<br />
auf Empfänger 0 (= alle) umstellen.<br />
<br />
[[Bild:SRCP_GM.png]]<br />
<br />
<br />
''Anmerkung von svesch: Müssen wir uns über Timeouts Gedanken machen? Wie lange soll ein anfragender Client auf Antworten warten? Generiert der Server ggf eine Timeoutnachricht? Wenn der Server schon beim Empfang einer "SET 0 GM"-Anfrage sieht, dass er damit keinen Empfänger erreichen kann, sollte er eine entsprechende Meldung an den Anfrager generieren. Beispiel: Der Anfrager ist der einzige Client, der beim Server angemeldet ist.''<br />
<br />
<br />
==== Vorschläge zur Trafficminimierung ====<br />
<br />
* Wenn an einen SRCP-Server eine CRCF-Broadcastanfrage gestellt wird, muss er dann eine INFO-Nachricht generieren? Es kann ja sein, dass er selber auf die Anfrage antworten kann. Gerade bei dynamischen Daten kann der Server möglicherweise am besten Auskunft geben. <br />
<br />
* CRCF-Broadcastanfragen werden vom Server per INFO-Meldung an alle angemeldeten Clients weitergeleitet. An den Anfrager selber sollte die INFO-Meldung jedoch nicht weitergeleitet werden.<br />
<br />
* Ein Client sollte selber darüber entscheiden, ob er CRCF-Broadcasts empfängt. Defaultmäßig ist dies ausgeschalten. Wie das Ein- oder Ausschalten funktioniert, wäre zu diskutieren.<br />
<br />
<br />
== Glossar ==<br />
<br />
'''CRCF-Broadcastanfrage''' Eine SRCP-Nachricht in Form von "SET 0 GM <AntwortID> 0 CONFGET <messagetext>".</div>Stefan Bormannhttp://der-moba.de/index.php?title=FREMO&diff=11898FREMO2007-01-28T13:21:11Z<p>Stefan Bormann: FREMO-DCC Link eingefuegt</p>
<hr />
<div>[[Bild:Fremo JT2003.jpg|thumb|350px|FREMO Jahrestagung 2003 in Calw - verschiedene Modulanlagen in einer Dreifeldturnhalle]]<br />
Der '''Freundeskreis Europäischer Modellbahner e.V.''', abgekürzt '''FREMO''' ist ein Verein nach deutschem Vereinsrecht. Der Verein wurde 1981 gegründet und hat etwa 1000 Mitglieder in 15 europäischen Ländern. Der Vereins legt in seiner Satzung fest: ''"Zweck des Vereins ist es, das Modellbahnerhobby, insbesondere dessen kreativitäts- und aktivitätsbezogenen Aspekte sowie den persönlichen Kontakt unter den Modellbahnern auf überregionaler und internationaler Ebene zu fördern."''<br />
<br />
Inhaltliche Schwerpunkte des Vereinslebens sind Bau und [[Normung]] von [[Modularer Modelleisenbahnbau|Modelleisenbahn-Modulen]] sowie die Veranstaltung von Treffen auf denen die einzelnen Module zu vorab geplanten Modularrangements [[Epoche |epochengerecht]] zusammengestellt werden. Das bedeutet, dass nur in der Realität zeitlich zueinander passende Fahrzeuge, dargestellte Bauten und technische Einrichtungen dargestellt und eingesetzt werden. Auf diesem Arrangement wird dann nach der Eisenbahnbetrieb nach [[Fahrplan]] durchgeführt. Jeder Zug hat einen [[Zugführer]], der zumeist auch die Aufgabe des [[Triebfahrzeugführer|Lokführers]] übernimmt und viele Betriebsstellen haben einen [[Fahrdienstleiter]]. Daher werden Modularrangements von mehreren Personen betrieben. Teilweise wird im [[Zugleitbetrieb]] gefahren, so dass ein [[Zugleiter]] notwendig wird.<br />
<br />
Weitere Schwerpunkte sind die Entwicklung einer unter dem Namen ''[http://fremodcc.sourceforge.net/dcc_d.html Fremo-DCC]'' bekannten [[Steuerung der Modelleisenbahn#Digitalsteuerung|digitalen Steuerung]], die Umsetzung möglichst maßstabsgetreuer Bauweisen sowie die Herausgabe der Zeitschrift ''[[Hp1 Modellbahn]]''.<br />
<br />
==Module (FreModule)==<br />
Um auf den Fremotreffen die Module der einzelnen Mitglieder miteinander verbinden zu können, sind entsprechende Normen geschaffen worden. Die Modulsysteme werden nach ihrer [[Maßstäbe der Modelleisenbahn|Baugröße]] und bedarfsweise nach einem Thema bezeichnet. Die wichtigsten Systeme sind: 0, 0m, 0e, H0-Europa, H0-USA, H0PS, H0m, H0m-Rhätische Bahn, H0e, H0f, N. Innerhalb dieser Systeme gibt es wiederum Gruppen, die sich auf einzelne Themen festlegen. <br />
<br />
Hauptvoraussetzung ist ein definierter Übergang zwischen den einzelnen Modulen, um die jeweils durchgehenden [[Gleis]]e miteinander verbinden zu können.<br />
<br />
Ein weiterer Gesichtspunkt (neben Epoche und Vorbildregion) stellt auch das verwendete Gleismaterial dar: Die Geometrie von Gleisen aus Großserienfertigung unterscheidet sich deutlich vom Vorbild; häufig ist auch die Höhe des Schienenprofils der Modellgleise größer als eine genaue [[Maßstab (Verhältnis)|Maßstab]]sumrechnung ergibt. Am Gleismaterial orientiert sich die Geometrie der Fahrzeugräder. Die Umsetzung eines möglichst vorbildnahen Rad-Schiene-Systems gehört zu den wichtigsten Themen des FREMO.<br />
<br />
Die Modulsysteme des FREMO legen neben dem genormten Modulübergang keine weiteren Abmaße der Module fest. Die Modulsysteme H0-Europa und N kennen ein- und zweigleisige Modulübergänge, alle anderen Systeme haben eine eingleisige Schnittstelle. <br />
<br />
FreModule unterscheiden Strecken- und Betriebsstellenmodule. Streckenmodule enthalten keine [[Eisenbahnweichen]] und können elektrisch einfach ausgeführt werden; sie werden von den Zügen zwischen den Betriebsstellen durchfahren. Unter den Betriebsstellenmodulen versteht man neben [[Eisenbahnsicherungs-_und_-signaltechnik#Bahnhof|Bahnhöfen]] auch die [[Bahnanlage der freien Strecke]], wie [[Eisenbahnsicherungs-_und_-signaltechnik#Anschlußstellen_(Anst)_und_Ausweichanschlußstellen_(Awanst)|Anschlussstellen]], [[Eisenbahnsicherungs-_und_-signaltechnik#Abzweigstellen|Abzweigstellen]], [[Eisenbahnsicherungs-_und_-signaltechnik#Blockstellen|Blockstellen]] und [[Eisenbahnsicherungs-_und_-signaltechnik#Haltepunkte|Haltepunkte]].<br />
<br />
==Weblinks==<br />
[http://www.fremo.org Homepage des Vereins]<br />
<br />
[[Kategorie:Verein]]</div>Stefan Bormannhttp://der-moba.de/index.php?title=SRCP-Erweiterungen&diff=11897SRCP-Erweiterungen2007-01-28T12:58:15Z<p>Stefan Bormann: /* Aenderung nochmal gemacht (wiki hat mich ueberlistet) */</p>
<hr />
<div>==Das initiale Posting==<br />
<br />
Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.<br />
<br />
Hier der initiale Eintrag:<br />
<br />
Hallo SRCP-Fans!<br />
<br />
ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich<br />
aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das<br />
mein erster Eintrag in der Gruppe ;).<br />
Während der Entwicklung kamen einige Ideen, die ich nun hier zur<br />
Diskussion stellen möchte:<br />
<br />
# Ich hätte gern einen Dienst für Clients, mit dem sie den Server (bzw. dessen IP-Adresse) finden können. Da gibt es sicher mehrere Möglichkeiten, ich dachte an Broadcast oder an eine DHCP-Option.<br />
# Stichwort CRCF: Was ist mit der Entwicklung? Ich hätte gern dieses Feature für SRCP und würde mich ggf. an der Mitentwicklung beteiligen.<br />
<br />
Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art<br />
Stammtisch?<br />
<br />
Gruß, Sven.<br />
<br />
Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.<br />
<br />
<br />
==SRCP-Server-Suchdienst==<br />
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ Zeroconf]-Systemdienst (DNS-SD/mDNS) einzusetzen. Dieser ermöglicht die Suche bzw. das Veröffentlichen beliebiger Systemdiente durch das Versenden eines ServiceDiscovery-Multicasts. Es existieren hierfür derzeit zwei zueinander kompatible Implementierungen, die beide als OpenSource freigegeben sind:<br />
<br />
* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.<br />
* [http://avahi.org/ Avahi], als praktisch schon etablierter Standard für Linux.<br />
<br />
Unter anderem ist es hiermit möglich, Angaben über die Portnummer zu veröffentlichen, auf der der Server seinen Dienst anbietet. Da es für das SRCP-Protokoll noch keine offiziell über [http://www.iana.org/ IANA/IETF] reservierte Portnummer gibt, hat ein SRCP-Administrator problemlos die Freiheit, einen von der aktuellen SRCP-Spezifikation abweichenden Wert zu wählen. Auch die Anzahl der in einem Netz betriebenen SRCP-Server ist damit nicht eingeschränkt.<br />
<br />
Dem Administrator eines SRCP-Servers bleibt es überlassen, auf dem gleichen Rechner auch einen „Zeroconf“-Systemdienst einzurichten. Er muß, wenn er auf seiner Modellbahn entsprechende SRCP-Clients benutzen möchte, das Programm installieren und so konfigurieren, dass der SRCP-Dienst veröffentlicht wird. Alternativ kann ein SRCP-Server sich auch automatisiert beim Zeroconf-Dienst anmelden. Die eigentliche Arbeit für die Nutzung des SD-Dienstes liegt beim Entwickler des „Einsteck-und-Spiel“-SRCP-Clients, denn dieser SRCP-Client muß nicht nur SRCP sprechen, sondern auch noch ein DNS-SD/mDNS-Client sein.<br />
<br />
Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service<br />
(Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.<br />
<br />
<service-group><br />
<name replace-wildcards="yes">srcpd on %h</name><br />
<service protocol="any"><br />
<type>_srcp._tcp</type><br />
<host-name>srcp.example.com</host-name><br />
<port>12345</port><br />
<txt-record>SRCP auf Mobaserver</txt-record><br />
</service><br />
</service-group><br />
<br />
==CRCF-Erweiterungen==<br />
<br />
Obwohl CRCF (Common Railroad Configuration Files) vor einigen Jahren einmal vorgeschlagen wurde, wurde es nicht angenommen, da es möglicherweise zu wenig Interessenten fand. Umso mehr Interessenten fanden sich nun in dieser Diskussion. Das deutet darauf hin, dass CRCF weiterhin ein Thema ist. Über die Idee von CRCF hinaus gab es einige weitgehendere Ideen dazu.<br />
<br />
<br />
===Anforderungen an CRCF===<br />
<br />
* Umständlich Eingabe von Informationen über Loks und Zubehör soll entfallen<br />
* Anlagenweite Anzeige von Klartextnamen anstatt von Adressen<br />
* Im Bezug auf den Server-Suchdienst könnte CRCF die Hostnamen (IP-Adressen) der SRCP-Server verwalten<br />
* Verwaltung statischer Informationen<br />
* Verwaltung dynamischer Informationen<br />
* CRCF in ausdruckbarer Form<br />
* Gliederung der CRCF<br />
* SRCP-Server sollten Zugriff auf die CRCF erhalten<br />
* Kommunikation zwischen Clients<br />
<br />
<br />
===Fragestellungen===<br />
<br />
* Wo soll die CRCF liegen?<br />
* Wie soll der Auskunftsdienst aussehen?<br />
* Wie sollen dynamische Informationen von der CRCF verwaltet werden?<br />
* Betrifft die Kommunikation zwischen Clients die CRCF?<br />
<br />
Folgendes Schema sollte als Grundlage für weitere Diskussionen dienen:<br />
<br />
(TODO: Abbildung)<br />
<br />
<br />
===Implementierungsvorschläge===<br />
<br />
====Datenablage gemäß CRCF Spezifikation 0.2.0====<br />
* basiert auf SRCP<br />
* physikalisch liegen die CRCF-Daten beim SRCP-Server<br />
* Auskunftdienst ist Bestandteil von SRCP (Befehl CONFGET)<br />
* ist praktisch auf SRCP 0.7.1 ausgerichtet, deswegen fehlen wichtige Details der 0.8.X-Welt, wie z.B. Busse<br />
* unterstützt die CRCF als textbasierte Dateien<br />
* Verwaltung der Daten in Sinne von SRCP -> d.h. Die einzelnen Datenfelder kommen aus der SRCP-Welt<br />
* hält ausschliesslich statische Daten bereit<br />
* enthält auch Daten über die Eigenschaften eines Servers<br />
* pro SRCP-Server eine CRCF<br />
<br />
====Datenablage bei einem spezialisierten SRCP-Client====<br />
* die CRCF-Daten liegen bei einem SRCP-Client<br />
* Anfragen an die CRCF erfolgen zunächst an den SRCP-Server, der die Daten an den spezialisierten Client weiterleitet<br />
* nutzt SRCP als Tunnel, da CRCF-Anfragen nur weitergeleitet werden<br />
* Auskunftsbefehl ist jedoch als SRCP-Kommando auszuführen<br />
* Durch das ungesehene Weiterleiten von Nachrichten durch den SRCP-Server wird eine Kommunikation zwischen Clients ermöglicht <br />
* der Client muss sich bei allen verfügbaren SRCP-Server anmelden, damit Daten anlagenweit verteilt werden können<br />
* Der Client kann dann konsistent statische und dynamische Daten verwalten<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* Verwaltung von Daten, die über die SRCP-Welt hinausgehen, beispielsweise die Verwaltung von Fahrstrassen und kompletten Layouts<br />
<br />
====Datenablage bei einem separaten CRCF-Server====<br />
* Auskunftsdienst muss als neues Protokoll implementiert werden<br />
* SRCP-Clients sowie SRCP-Server können anfragen<br />
* Verwaltung von rein statischen Daten<br />
* Falls zusätzlich zum Auskunftsdienst ein Meldedienst implementiert wird, können auch dynamische Daten verwaltet werden<br />
* Kommunikation zwischen Clients könnte mittels einer Mailboxfunktion möglich werden<br />
* das SRCP-Protokoll wird nicht geändert, CRCF existiert parallel<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* SRCP-Server können Meldungen an die CRCF senden, um deren Inhalt zu aktualisieren<br />
<br />
====Bereitstellung der CRCF-Daten via Zeroconf-Dienst====<br />
<br />
* ...<br />
<br />
===Erweiterung des bisherigen Befehlsvorrats===<br />
Der bisherige Namensraum von CRCF umfaßt keine Befehle, die Objekte einer höheren Abstraktionsebene beschreiben. Für die Attribute dieser makroskopischen Objekte gibt es ebenfalls noch keine Festlegung. Zum Teil sind die Werte dieser Attribute statisch zum Teil ändern sich sich während des Betriebs. Der Bedarf für folgende Begriffe ist vorhanden:<br />
<br />
; Stellwerk (RWCC, Railway Control Center)<br />
:: Steuerungsinstanz, die Fahrstraßen verwaltet, für ein oder mehrere Bahnhöfe zuständig ist, Zugmeldungen abwickelt, ihr zuständiges Streckennetz kennt, einzuhaltende Geschwindigkeiten überwacht und bei Überschreitungen eingreift etc.<br />
; Gleisbild (LAYOUT)<br />
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, etc.<br />
; Fahrstraße (ROUTE)<br />
:: Sicherheitstechnisch überwachter Streckenabschnitt innerhalb eines Stellwerks, der über Informationen zur Start- und Zielsignal, Soll-Weichenstellungen, Freimeldeabschnitte, Typinformation (für anzuwendenden Regelsatz), den aktuellen Zustand (eingestellt, aufgelöst, reserviert, teilaufgelöst) etc. verfügt.<br />
; Weichenstraße (?)<br />
:: Sammlung schaltbarer Magnetartikel und ihrer Sollstellungen ohne sicherheitstechnische Überwachung <br />
:: Anmerkung von svesch: Das ist meiner Meinung nach kein neues Objekt, das ist nur eine Liste von GAs.<br />
; Zugsteuerung (TNCC, Train Control Center)<br />
:: Instanz, die die Logistik eines gegebenen Vorrats an Zügen übernimmt z.B. fahrplangesteuerte Fahrten von Zügen zwischen Bahnhöfen<br />
; Zug (TRAIN)<br />
:: Instanz, die über ihre Zugnummer identifizierbar ist, eine oder mehrere Lokomotiven ansteuert, Informationen zu Typ und Länge verfügt etc.<br />
<br />
(TODO: weitere ergänzen)<br />
<br />
==SRCP-Erweiterungen==<br />
Der bisherige Umfang des SRCP-Protokolls definiert keine Möglichkeit, mit der SRCP-Clients untereinander direkt Informationen austauschen können. Ein Bedarf dafür ist jedoch durchaus gegeben, wie folgende Auflistung zeigt:<br />
<br />
* Zugmeldungen zwischen Stellwerken<br />
* Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)<br />
* Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung<br />
* Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware<br />
* Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz<br />
* Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation (FIXME: falsch einsortiert)<br />
<br />
Weiterhin ist es mit SRCP prinzipiell möglich, eine Modellbahnanlage über mehrere SRCP-Server zu bedienen, es gibt aber bisher kein Konzept, das einen Informationsübergang zwischen den Server-Bereichen erlaubt.<br />
<br />
Zur Realisierung dieser neu zu implementierenden Informationswege wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.<br />
<br />
<br />
===Neuer Befehl im Kommandomodus===<br />
====Bewertung des Vorschlags====<br />
<br />
Die Implementierung wird nicht weiterverfolgt, da der Vorschlag zur neuen Gerätegruppe besser ins bisherige SRCP paßt. Die hier andiskutierten CRCF-Nachrichten können mit dem anderen Vorschlag ebenfalls transportiert werden.<br />
<br />
====Vorschlag====<br />
Die aktuell SRCP-Spezifikation umfaßt für den Kommandomodus einen definierten Satz an Befehlen, die in der folgenden allgemeinen Syntax an den Server gesendet werden:<br />
<br />
<kommando> <kommandoparameter> <br />
<br />
Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:<br />
<br />
<kommando> <bus> <gerätegruppe> <parameter><br />
<br />
Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.<br />
<br />
Vom Server abgearbeitete Befehle werden an alle im Infomodus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ mit der folgenden allgemeinen Syntax weitergeleitet:<br />
<br />
<codenr> INFO <bus> <gerätegruppe> <parameter><br />
<br />
Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.<br />
<br />
Von dieser Situation ausgehend, kann ein neues Kommando ergänzt werden, dass von SRCP-Server selbst nur zum Weiterleiten einer Nachricht an die angeschlossenen SRCP-Clients genutzt wird. Den Inhalt der Nachricht muß der SRCP-Server nicht interpretieren. Die Form der Nachricht kann/soll/muß den gängigen SRCP-Konventionen bezüglich Zeichensatz, Länge etc. genügen.<br />
<br />
Ein erster (anarchischer) Ansatz könte in SRCP 0.8-Terminologie so aussehen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
ECHO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 ECHO <message><br />
<br />
Einzweiter, mehr geordneter Ansatz, schreibt die Verwendung definierter Befehle (SRCP-Makros) vor, analog also beispielsweise so:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
MACRO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 MACRO <message><br />
<br />
Wobei <message> diesmal eine Folge von definierten (genormten) Befehlen inklusive deren Wert-Parametern sein muß. Diese Makros müssen natürlich den Kommunikationsbedarf der Clients (Frage/Antwort-Spiele) abdecken.<br />
<br />
Der dritte Ansatz wäre, statt der neu zu erfindenden Makros, CRCF zu benutzen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
CRCF 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 CRCF <message><br />
<br />
Der Inhalt von <message> wäre dann eine CRCF-Befehlsfolge.<br />
<br />
Angenommen eine Ablaufsteuerung (als eigener SRCP-Client) möchte eine Fahrstraße einstellen, dann sendet er an das zuständige Stellwerk folgende (CRCF-)Befehlsfolge:<br />
<br />
ROUTE <routeid> SET STATE 1<br />
<br />
Den Erfolg bekommt er dann vom Stellwerk zurückgemeldet oder kann ihn auch abfragen z.B. gemäß:<br />
<br />
ROUTE <routeid> GET STATE<br />
<br />
Den Bedarf, dass ein SRCP-Client einem Stellwerk Daten zur Konfiguration von Fahrstraßen sendet, wäre prinzipiell auch möglich:<br />
<br />
ROUTE <routeid> ADD GA <busid> <address> <port> <state><br />
<br />
Oder entfernen:<br />
<br />
ROUTE <routeid> REMOVE GA <busid> <address><br />
<br />
Um eine Client-Client-Verbindung zu unterhalten, müßte der Sender eines CRCF-Befehls seine<br />
SRCP-Session-ID immer mitsenden, dann könnte die Antwort zielgerichtet erfolgen:<br />
<br />
CRCF 0 <sender-sessionid> <empfänger-sessionid> <CRCF-message><br />
<br />
Mit dem Inhalt von <sessionid> ließe sich ein CRCF-Broadcast einfach von einer Punkt-zu-Punkt-Verbindung unterscheiden:<br />
<br />
# Der Wert ist 0: Broadcast<br />
# Der Wert ist >0: Punkt-zu-Punkt-Verbindung<br />
<br />
Auch das Thema "Zugbeeinflussung" läßt sich hiermit darstellen. Ein Zug muß während seiner Fahrt Geschwindigkeitsregeln einhalten, die das Stellwerk überwacht. Bei Überschreitungen sendet das Stellwerk einen Abbremsbefehl:<br />
<br />
CRCF 0 <sender-session-id> 0 TRAIN <train-id> SPEED SET 0<br />
<br />
===Neuer Sitzungstyp===<br />
<br />
====Bewertung====<br />
<br />
Die Diskussion dauert noch an, daher ist keine abschliessende Bewertung möglich<br />
<br />
====Vorschlagstext====<br />
<br />
Die Implementationen von CRCF bzw. Generic Messages und den bisher definierten SRCP-Sitzungen werden komplett getrennt.<br />
<br />
Motivation:<br />
* Ermöglicht Kapselung von unterschiedlichen Client-Funktionalitäten: die bestehenden Sitzungen und Generic Messages sind für komplett unterschiedliche Zwecke gedacht. Die bisherigen Steuerungs-Sitzungen dienen der Kommunikation mit der Modellbahn-Hardware, Generic Messages dienen der Kommunikation der Clients untereinander.<br />
* Dies senkt die Anforderungen an einen reinen Steuerungs-Server, er muss Generic Messages nicht unterstützen.<br />
* Es erspart mobilen Eingabegeräten z.B. einem Handregler den extremen Traffic, den intelligentere stationäre Clients untereinander haben.<br />
<br />
Bei der Einschätzung des Programmieraufwands gehen die Meinungen auseinander. Die einen sehen Zusatzaufwand in der dritten TCP-Verbindung, andererseits erhöht die Kapselung der Funktionalitäten die Wartbarkeit des Systems.<br />
<br />
Eigene Sitzungen trennen sowohl den Namensraum für Steuerung und Generic Messages als auch den durch beide Kommunikationsformen entstehenden Netzwerkverkehr:<br />
<br />
SET PROTOCOL GM 0.3<br />
SET CONNECTIONMODE GM INFO|COMMAND<br />
<br />
Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig. Alternativ ist ein Systemdienst möglich, der nur GM-Sitzungen, aber keine Steuerungs-Sitzungen unterstütz.<br />
<br />
===Neue Gerätegruppe===<br />
<br />
====Bewertung====<br />
<br />
Allgemein nutzbare Kommunikationsstrecke. SRCP muß um einige<br />
Details erweitert werden (siehe unten). Es entsteht ein permanenter<br />
Pflegedienst für Vergabe der Messagetypen (kann automatisiert werden)<br />
<br />
====Vorschlagstext====<br />
<br />
Für den generalisierten Messageaustausch wird eine neue Devicegruppe <br />
auf Bus 0 eingerichtet:<br />
<br />
GM Generic Message<br />
<br />
Die einzige (sinnvoll) anzuwendende Methode ist SET.<br />
<br />
Im Kommandomodus:<br />
<br />
SET 0 GM <AntwortID> <EmpfängerID> <messagetype> <messagetext><br />
<br />
EmpfängerID ist SessionID, die die Message<br />
erhalten soll. Ist diese 0, so wird die Message als Broadcast an<br />
alle INFO Sessions gesendet. Die AntwortID ist die SessionID (oder<br />
0) der INFO Session, an die eine evt. Antwortmessage gesendet<br />
werden soll.<br />
<br />
Im INFO Modus:<br />
<br />
INFO 0 GM <AntwortID> <EmpfängerID> <messagetype> <messagetext><br />
<br />
Für <messagetext> gelten die im SRCP üblichen Einschränkungen:<br />
*keine Leerzeichen (kann man durch Konvention z.B. durch URL Codierung umgehen).<br />
*maximale Zeilenlänge 1000 Zeichen (inkl. der Befehle & CRLF).<br />
<br />
<messagetype> ist ein zentral gepflegte Liste von Clientidentifiern um den Messagetyp erkennen zu können.<br />
<br />
Beispiel: Ein Client fragt nach den Einzelheiten des Gerätes GA 1 auf<br />
Bus 17. (Schritt A) Antwort an SessionID 45 erbeten.<br />
<br />
SET 0 GM 45 0 CRCF CONFGET 17 GA 1<br />
<br />
Wie der INFO aussieht, dürfte offensichtlich sein. Er geht an alle INFO Sessions.<br />
(Schritt B)<br />
<br />
INFO 0 GM 45 0 CRCF CONFGET 17 GA 1<br />
<br />
<br />
Wenn ein CRCF Service diese Message erhalten hat, sendet er eine<br />
passende Antwort an den SRCP Server (Schritt C)<br />
<br />
SET 0 GM 25 45 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Die Infosession des CRCF Services ist im Beispiel 25, die Antwort wird vom<br />
SRCP Server direkt an die SESSION 45 weitergeleitet.<br />
<br />
INFO 0 GM 25 45 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Der Nachrichtenfluß ist im Bild dargestellt. CA ist die Command Session von<br />
Client A, IA die Infosession. Client B (CRCF Server analog).<br />
<br />
Weitere Anfragen kann der Client direkt an Session 25 stellen. Er erhält<br />
die Info sofort, wenn Session 25 terminieren sollte. Dann kann er wieder<br />
auf Empfänger 0 (= alle) umstellen.<br />
<br />
[[Bild:SRCP_GM.png]]</div>Stefan Bormannhttp://der-moba.de/index.php?title=SRCP-Erweiterungen&diff=11895SRCP-Erweiterungen2007-01-26T18:44:55Z<p>Stefan Bormann: /* Alten Bewertungstext des neuen Sitzungstyps zum Vorschlagtext verschoben und umformuliert */</p>
<hr />
<div>==Das initiale Posting==<br />
<br />
Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.<br />
<br />
Hier der initiale Eintrag:<br />
<br />
Hallo SRCP-Fans!<br />
<br />
ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich<br />
aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das<br />
mein erster Eintrag in der Gruppe ;).<br />
Während der Entwicklung kamen einige Ideen, die ich nun hier zur<br />
Diskussion stellen möchte:<br />
<br />
# Ich hätte gern einen Dienst für Clients, mit dem sie den Server (bzw. dessen IP-Adresse) finden können. Da gibt es sicher mehrere Möglichkeiten, ich dachte an Broadcast oder an eine DHCP-Option.<br />
# Stichwort CRCF: Was ist mit der Entwicklung? Ich hätte gern dieses Feature für SRCP und würde mich ggf. an der Mitentwicklung beteiligen.<br />
<br />
Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art<br />
Stammtisch?<br />
<br />
Gruß, Sven.<br />
<br />
Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.<br />
<br />
<br />
==SRCP-Server-Suchdienst==<br />
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ Zeroconf]-Systemdienst (DNS-SD/mDNS) einzusetzen. Dieser ermöglicht die Suche bzw. das Veröffentlichen beliebiger Systemdiente durch das Versenden eines ServiceDiscovery-Multicasts. Es existieren hierfür derzeit zwei zueinander kompatible Implementierungen, die beide als OpenSource freigegeben sind:<br />
<br />
* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.<br />
* [http://avahi.org/ Avahi], als praktisch schon etablierter Standard für Linux.<br />
<br />
Unter anderem ist es hiermit möglich, Angaben über die Portnummer zu veröffentlichen, auf der der Server seinen Dienst anbietet. Da es für das SRCP-Protokoll noch keine offiziell über [http://www.iana.org/ IANA/IETF] reservierte Portnummer gibt, hat ein SRCP-Administrator problemlos die Freiheit, einen von der aktuellen SRCP-Spezifikation abweichenden Wert zu wählen. Auch die Anzahl der in einem Netz betriebenen SRCP-Server ist damit nicht eingeschränkt.<br />
<br />
Dem Administrator eines SRCP-Servers bleibt es überlassen, auf dem gleichen Rechner auch einen „Zeroconf“-Systemdienst einzurichten. Er muß, wenn er auf seiner Modellbahn entsprechende SRCP-Clients benutzen möchte, das Programm installieren und so konfigurieren, dass der SRCP-Dienst veröffentlicht wird. Alternativ kann ein SRCP-Server sich auch automatisiert beim Zeroconf-Dienst anmelden. Die eigentliche Arbeit für die Nutzung des SD-Dienstes liegt beim Entwickler des „Einsteck-und-Spiel“-SRCP-Clients, denn dieser SRCP-Client muß nicht nur SRCP sprechen, sondern auch noch ein DNS-SD/mDNS-Client sein.<br />
<br />
Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service<br />
(Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.<br />
<br />
<service-group><br />
<name replace-wildcards="yes">srcpd on %h</name><br />
<service protocol="any"><br />
<type>_srcp._tcp</type><br />
<host-name>srcp.example.com</host-name><br />
<port>12345</port><br />
<txt-record>SRCP auf Mobaserver</txt-record><br />
</service><br />
</service-group><br />
<br />
==CRCF-Erweiterungen==<br />
<br />
Obwohl CRCF (Common Railroad Configuration Files) vor einigen Jahren einmal vorgeschlagen wurde, wurde es nicht angenommen, da es möglicherweise zu wenig Interessenten fand. Umso mehr Interessenten fanden sich nun in dieser Diskussion. Das deutet darauf hin, dass CRCF weiterhin ein Thema ist. Über die Idee von CRCF hinaus gab es einige weitgehendere Ideen dazu.<br />
<br />
<br />
===Anforderungen an CRCF===<br />
<br />
* Umständlich Eingabe von Informationen über Loks und Zubehör soll entfallen<br />
* Anlagenweite Anzeige von Klartextnamen anstatt von Adressen<br />
* Im Bezug auf den Server-Suchdienst könnte CRCF die Hostnamen (IP-Adressen) der SRCP-Server verwalten<br />
* Verwaltung statischer Informationen<br />
* Verwaltung dynamischer Informationen<br />
* CRCF in ausdruckbarer Form<br />
* Gliederung der CRCF<br />
* SRCP-Server sollten Zugriff auf die CRCF erhalten<br />
* Kommunikation zwischen Clients<br />
<br />
<br />
===Fragestellungen===<br />
<br />
* Wo soll die CRCF liegen?<br />
* Wie soll der Auskunftsdienst aussehen?<br />
* Wie sollen dynamische Informationen von der CRCF verwaltet werden?<br />
* Betrifft die Kommunikation zwischen Clients die CRCF?<br />
<br />
Folgendes Schema sollte als Grundlage für weitere Diskussionen dienen:<br />
<br />
(TODO: Abbildung)<br />
<br />
<br />
===Implementierungsvorschläge===<br />
<br />
====Datenablage gemäß CRCF Spezifikation 0.2.0====<br />
* basiert auf SRCP<br />
* physikalisch liegen die CRCF-Daten beim SRCP-Server<br />
* Auskunftdienst ist Bestandteil von SRCP (Befehl CONFGET)<br />
* ist praktisch auf SRCP 0.7.1 ausgerichtet, deswegen fehlen wichtige Details der 0.8.X-Welt, wie z.B. Busse<br />
* unterstützt die CRCF als textbasierte Dateien<br />
* Verwaltung der Daten in Sinne von SRCP -> d.h. Die einzelnen Datenfelder kommen aus der SRCP-Welt<br />
* hält ausschliesslich statische Daten bereit<br />
* enthält auch Daten über die Eigenschaften eines Servers<br />
* pro SRCP-Server eine CRCF<br />
<br />
====Datenablage bei einem spezialisierten SRCP-Client====<br />
* die CRCF-Daten liegen bei einem SRCP-Client<br />
* Anfragen an die CRCF erfolgen zunächst an den SRCP-Server, der die Daten an den spezialisierten Client weiterleitet<br />
* nutzt SRCP als Tunnel, da CRCF-Anfragen nur weitergeleitet werden<br />
* Auskunftsbefehl ist jedoch als SRCP-Kommando auszuführen<br />
* Durch das ungesehene Weiterleiten von Nachrichten durch den SRCP-Server wird eine Kommunikation zwischen Clients ermöglicht <br />
* der Client muss sich bei allen verfügbaren SRCP-Server anmelden, damit Daten anlagenweit verteilt werden können<br />
* Der Client kann dann konsistent statische und dynamische Daten verwalten<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* Verwaltung von Daten, die über die SRCP-Welt hinausgehen, beispielsweise die Verwaltung von Fahrstrassen und kompletten Layouts<br />
<br />
====Datenablage bei einem separaten CRCF-Server====<br />
* Auskunftsdienst muss als neues Protokoll implementiert werden<br />
* SRCP-Clients sowie SRCP-Server können anfragen<br />
* Verwaltung von rein statischen Daten<br />
* Falls zusätzlich zum Auskunftsdienst ein Meldedienst implementiert wird, können auch dynamische Daten verwaltet werden<br />
* Kommunikation zwischen Clients könnte mittels einer Mailboxfunktion möglich werden<br />
* das SRCP-Protokoll wird nicht geändert, CRCF existiert parallel<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* SRCP-Server können Meldungen an die CRCF senden, um deren Inhalt zu aktualisieren<br />
<br />
====Bereitstellung der CRCF-Daten via Zeroconf-Dienst====<br />
<br />
* ...<br />
<br />
===Erweiterung des bisherigen Befehlsvorrats===<br />
Der bisherige Namensraum von CRCF umfaßt keine Befehle, die Objekte einer höheren Abstraktionsebene beschreiben. Für die Attribute dieser makroskopischen Objekte gibt es ebenfalls noch keine Festlegung. Zum Teil sind die Werte dieser Attribute statisch zum Teil ändern sich sich während des Betriebs. Der Bedarf für folgende Begriffe ist vorhanden:<br />
<br />
; Stellwerk (RWCC, Railway Control Center)<br />
:: Steuerungsinstanz, die Fahrstraßen verwaltet, für ein oder mehrere Bahnhöfe zuständig ist, Zugmeldungen abwickelt, ihr zuständiges Streckennetz kennt, einzuhaltende Geschwindigkeiten überwacht und bei Überschreitungen eingreift etc.<br />
; Gleisbild (LAYOUT)<br />
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, etc.<br />
; Fahrstraße (ROUTE)<br />
:: Sicherheitstechnisch überwachter Streckenabschnitt innerhalb eines Stellwerks, der über Informationen zur Start- und Zielsignal, Soll-Weichenstellungen, Freimeldeabschnitte, Typinformation (für anzuwendenden Regelsatz), den aktuellen Zustand (eingestellt, aufgelöst, reserviert, teilaufgelöst) etc. verfügt.<br />
; Weichenstraße (?)<br />
:: Sammlung schaltbarer Magnetartikel und ihrer Sollstellungen ohne sicherheitstechnische Überwachung <br />
:: Anmerkung von svesch: Das ist meiner Meinung nach kein neues Objekt, das ist nur eine Liste von GAs.<br />
; Zugsteuerung (TNCC, Train Control Center)<br />
:: Instanz, die die Logistik eines gegebenen Vorrats an Zügen übernimmt z.B. fahrplangesteuerte Fahrten von Zügen zwischen Bahnhöfen<br />
; Zug (TRAIN)<br />
:: Instanz, die über ihre Zugnummer identifizierbar ist, eine oder mehrere Lokomotiven ansteuert, Informationen zu Typ und Länge verfügt etc.<br />
<br />
(TODO: weitere ergänzen)<br />
<br />
==SRCP-Erweiterungen==<br />
Der bisherige Umfang des SRCP-Protokolls definiert keine Möglichkeit, mit der SRCP-Clients untereinander direkt Informationen austauschen können. Ein Bedarf dafür ist jedoch durchaus gegeben, wie folgende Auflistung zeigt:<br />
<br />
* Zugmeldungen zwischen Stellwerken<br />
* Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)<br />
* Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung<br />
* Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware<br />
* Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz<br />
* Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation (FIXME: falsch einsortiert)<br />
<br />
Weiterhin ist es mit SRCP prinzipiell möglich, eine Modellbahnanlage über mehrere SRCP-Server zu bedienen, es gibt aber bisher kein Konzept, das einen Informationsübergang zwischen den Server-Bereichen erlaubt.<br />
<br />
Zur Realisierung dieser neu zu implementierenden Informationswege wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.<br />
<br />
<br />
===Neuer Befehl im Kommandomodus===<br />
====Bewertung des Vorschlags====<br />
<br />
Die Implementierung wird nicht weiterverfolgt, da der Vorschlag zur neuen Gerätegruppe besser ins bisherige SRCP paßt. Die hier andiskutierten CRCF-Nachrichten können mit dem anderen Vorschlag ebenfalls transportiert werden.<br />
<br />
====Vorschlag====<br />
Die aktuell SRCP-Spezifikation umfaßt für den Kommandomodus einen definierten Satz an Befehlen, die in der folgenden allgemeinen Syntax an den Server gesendet werden:<br />
<br />
<kommando> <kommandoparameter> <br />
<br />
Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:<br />
<br />
<kommando> <bus> <gerätegruppe> <parameter><br />
<br />
Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.<br />
<br />
Vom Server abgearbeitete Befehle werden an alle im Infomodus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ mit der folgenden allgemeinen Syntax weitergeleitet:<br />
<br />
<codenr> INFO <bus> <gerätegruppe> <parameter><br />
<br />
Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.<br />
<br />
Von dieser Situation ausgehend, kann ein neues Kommando ergänzt werden, dass von SRCP-Server selbst nur zum Weiterleiten einer Nachricht an die angeschlossenen SRCP-Clients genutzt wird. Den Inhalt der Nachricht muß der SRCP-Server nicht interpretieren. Die Form der Nachricht kann/soll/muß den gängigen SRCP-Konventionen bezüglich Zeichensatz, Länge etc. genügen.<br />
<br />
Ein erster (anarchischer) Ansatz könte in SRCP 0.8-Terminologie so aussehen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
ECHO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 ECHO <message><br />
<br />
Einzweiter, mehr geordneter Ansatz, schreibt die Verwendung definierter Befehle (SRCP-Makros) vor, analog also beispielsweise so:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
MACRO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 MACRO <message><br />
<br />
Wobei <message> diesmal eine Folge von definierten (genormten) Befehlen inklusive deren Wert-Parametern sein muß. Diese Makros müssen natürlich den Kommunikationsbedarf der Clients (Frage/Antwort-Spiele) abdecken.<br />
<br />
Der dritte Ansatz wäre, statt der neu zu erfindenden Makros, CRCF zu benutzen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
CRCF 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 CRCF <message><br />
<br />
Der Inhalt von <message> wäre dann eine CRCF-Befehlsfolge.<br />
<br />
Angenommen eine Ablaufsteuerung (als eigener SRCP-Client) möchte eine Fahrstraße einstellen, dann sendet er an das zuständige Stellwerk folgende (CRCF-)Befehlsfolge:<br />
<br />
ROUTE <routeid> SET STATE 1<br />
<br />
Den Erfolg bekommt er dann vom Stellwerk zurückgemeldet oder kann ihn auch abfragen z.B. gemäß:<br />
<br />
ROUTE <routeid> GET STATE<br />
<br />
Den Bedarf, dass ein SRCP-Client einem Stellwerk Daten zur Konfiguration von Fahrstraßen sendet, wäre prinzipiell auch möglich:<br />
<br />
ROUTE <routeid> ADD GA <busid> <address> <port> <state><br />
<br />
Oder entfernen:<br />
<br />
ROUTE <routeid> REMOVE GA <busid> <address><br />
<br />
Um eine Client-Client-Verbindung zu unterhalten, müßte der Sender eines CRCF-Befehls seine<br />
SRCP-Session-ID immer mitsenden, dann könnte die Antwort zielgerichtet erfolgen:<br />
<br />
CRCF 0 <sender-sessionid> <empfänger-sessionid> <CRCF-message><br />
<br />
Mit dem Inhalt von <sessionid> ließe sich ein CRCF-Broadcast einfach von einer Punkt-zu-Punkt-Verbindung unterscheiden:<br />
<br />
# Der Wert ist 0: Broadcast<br />
# Der Wert ist >0: Punkt-zu-Punkt-Verbindung<br />
<br />
Auch das Thema "Zugbeeinflussung" läßt sich hiermit darstellen. Ein Zug muß während seiner Fahrt Geschwindigkeitsregeln einhalten, die das Stellwerk überwacht. Bei Überschreitungen sendet das Stellwerk einen Abbremsbefehl:<br />
<br />
CRCF 0 <sender-session-id> 0 TRAIN <train-id> SPEED SET 0<br />
<br />
===Neuer Sitzungstyp===<br />
<br />
====Bewertung====<br />
<br />
Die Implementationen von CRCF und SRCP werden komplett getrennt.<br />
<br />
Vorteile/Gründe:<br />
* Ermöglicht Kapselung von unterschiedlichern Client-Funktionalitäten: SRCP und CRCF sind für komplett unterschiedliche Zwecke gedacht, SRCP dient der Kommunikation mit der Modellbahn-Hardware, CRCF dient der Kommunikation der Clients untereinander.<br />
* Dies senkt die Anforderungen an einen reinen SRCP-Server<br />
* Es erspart mobilen Eingabegeräten z.B. einem Handregler den extremen Traffic, den intelligentere stationäre Clients untereinander haben.<br />
<br />
Der Programmieraufwand zur Unterhaltung der zusätzlichen Netzwerkverbindungen sollte sich nicht unterscheiden, da fuer SRCP alleine auch schon mehr als eine TCP-Verbindung nötig ist.<br />
<br />
====Vorschlagstext====<br />
<br />
Die Implementationen von CRCF bzw. Generic Messages und den bisher definierten SRCP-Sitzungen werden komplett getrennt.<br />
<br />
Motivation:<br />
* Ermöglicht Kapselung von unterschiedlichen Client-Funktionalitäten: die bestehenden Sitzungen und Generic Messages sind für komplett unterschiedliche Zwecke gedacht. Die bisherigen Steuerungs-Sitzungen dienen der Kommunikation mit der Modellbahn-Hardware, Generic Messages dienen der Kommunikation der Clients untereinander.<br />
* Dies senkt die Anforderungen an einen reinen Steuerungs-Server, er muss Generic Messages nicht unterstützen.<br />
* Es erspart mobilen Eingabegeräten z.B. einem Handregler den extremen Traffic, den intelligentere stationäre Clients untereinander haben.<br />
<br />
Bei der Einschätzung des Programmieraufwands gehen die Meinungen auseinander. Die einen sehen Zusatzaufwand in der dritten TCP-Verbindung, andererseits erhöht die Kapselung der Funktionalitäten die Wartbarkeit des Systems.<br />
<br />
Eigene Sitzungen trennen sowohl den Namensraum für Steuerung und Generic Messages als auch den durch beide Kommunikationsformen entstehenden Netzwerkverkehr:<br />
<br />
SET PROTOCOL GM 0.3<br />
SET CONNECTIONMODE GM INFO|COMMAND<br />
<br />
Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig. Alternativ ist ein Systemdienst möglich, der nur GM-Sitzungen, aber keine Steuerungs-Sitzungen unterstütz.<br />
<br />
===Neue Gerätegruppe===<br />
<br />
====Bewertung====<br />
<br />
Allgemein nutzbare Kommunikationsstrecke. SRCP muß um einige<br />
Details erweitert werden (siehe unten). Es entsteht ein permanenter<br />
Pflegedienst für Vergabe der Messagetypen (kann automatisiert werden)<br />
<br />
====Vorschlagstext====<br />
<br />
Für den generalisierten Messageaustausch wird eine neue Devicegruppe eingerichtet:<br />
<br />
GM Generic Message<br />
<br />
Die einzige (sinnvoll) anzuwendende Methode ist SET.<br />
Im SRCP ist noch festzulegen, das eine Busnummer nicht als<br />
SessionID vergeben werden darf.<br />
<br />
Im Kommandomodus:<br />
<br />
SET <EmpfängerID> GM <AntwortID> <messagetype> <messagetext><br />
<br />
EmpfängerID ist die Busnummer oder SessionID, die die Message<br />
erhalten soll. Ist diese 0, so wird die Message als Broadcast an<br />
alle INFO Sessions gesendet. Die AntwortID ist die SessionID (oder<br />
0) der INFO Session, an die eine evt. Antwortmessage gesendet<br />
werden soll.<br />
<br />
Im INFO Modus:<br />
<br />
INFO <EmpfängerID> GM <AntwortID> <messagetype> <messagetext><br />
<br />
<br />
Für <messagetext> gelten die im SRCP üblichen Einschränkungen:<br />
*keine Leerzeichen (kann man durch Konvention z.B. durch URL Codierung umgehen).<br />
*maximale Zeilenlänge 1000 Zeichen (inkl. der Befehle & CRLF).<br />
<br />
<messagetype> ist ein zentral gepflegte Liste von Clientidentifiern um den Messagetyp erkennen zu können.<br />
<br />
Beispiel: Ein Client fragt nach den Einzelheiten des Gerätes GA 1 auf<br />
Bus 17. (Schritt A)<br />
<br />
SET 0 GM 45 CRCF CONFGET 17 GA 1<br />
<br />
Wie der INFO aussieht, dürfte offensichtlich sein. Er geht an alle INFO Sessions.<br />
(Schritt B)<br />
<br />
INFO 0 GM 45 CRCF CONFGET 17 GA 1<br />
<br />
<br />
Wenn ein CRCF Service diese Message erhalten hat, sendet er eine<br />
passende Antwort an den SRCP Server (Schritt C)<br />
<br />
SET 45 GM 25 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Die Infosession des CRCF Services ist im Beispiel 25, die Antwort wird vom<br />
SRCP Server direkt an die SESSION 45 weitergeleitet.<br />
<br />
INFO 45 GM 25 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Der Nachrichtenfluß ist im Bild dargestellt. CA ist die Command Session von<br />
Client A, IA die Infosession. Client B (CRCF Server analog)<br />
[[Bild:SRCP_GM.png]]</div>Stefan Bormannhttp://der-moba.de/index.php?title=SRCP-Erweiterungen&diff=11894SRCP-Erweiterungen2007-01-26T18:28:08Z<p>Stefan Bormann: /* Bewertung geleert */</p>
<hr />
<div>==Das initiale Posting==<br />
<br />
Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.<br />
<br />
Hier der initiale Eintrag:<br />
<br />
Hallo SRCP-Fans!<br />
<br />
ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich<br />
aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das<br />
mein erster Eintrag in der Gruppe ;).<br />
Während der Entwicklung kamen einige Ideen, die ich nun hier zur<br />
Diskussion stellen möchte:<br />
<br />
# Ich hätte gern einen Dienst für Clients, mit dem sie den Server (bzw. dessen IP-Adresse) finden können. Da gibt es sicher mehrere Möglichkeiten, ich dachte an Broadcast oder an eine DHCP-Option.<br />
# Stichwort CRCF: Was ist mit der Entwicklung? Ich hätte gern dieses Feature für SRCP und würde mich ggf. an der Mitentwicklung beteiligen.<br />
<br />
Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art<br />
Stammtisch?<br />
<br />
Gruß, Sven.<br />
<br />
Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.<br />
<br />
<br />
==SRCP-Server-Suchdienst==<br />
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ Zeroconf]-Systemdienst (DNS-SD/mDNS) einzusetzen. Dieser ermöglicht die Suche bzw. das Veröffentlichen beliebiger Systemdiente durch das Versenden eines ServiceDiscovery-Multicasts. Es existieren hierfür derzeit zwei zueinander kompatible Implementierungen, die beide als OpenSource freigegeben sind:<br />
<br />
* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.<br />
* [http://avahi.org/ Avahi], als praktisch schon etablierter Standard für Linux.<br />
<br />
Unter anderem ist es hiermit möglich, Angaben über die Portnummer zu veröffentlichen, auf der der Server seinen Dienst anbietet. Da es für das SRCP-Protokoll noch keine offiziell über [http://www.iana.org/ IANA/IETF] reservierte Portnummer gibt, hat ein SRCP-Administrator problemlos die Freiheit, einen von der aktuellen SRCP-Spezifikation abweichenden Wert zu wählen. Auch die Anzahl der in einem Netz betriebenen SRCP-Server ist damit nicht eingeschränkt.<br />
<br />
Dem Administrator eines SRCP-Servers bleibt es überlassen, auf dem gleichen Rechner auch einen „Zeroconf“-Systemdienst einzurichten. Er muß, wenn er auf seiner Modellbahn entsprechende SRCP-Clients benutzen möchte, das Programm installieren und so konfigurieren, dass der SRCP-Dienst veröffentlicht wird. Alternativ kann ein SRCP-Server sich auch automatisiert beim Zeroconf-Dienst anmelden. Die eigentliche Arbeit für die Nutzung des SD-Dienstes liegt beim Entwickler des „Einsteck-und-Spiel“-SRCP-Clients, denn dieser SRCP-Client muß nicht nur SRCP sprechen, sondern auch noch ein DNS-SD/mDNS-Client sein.<br />
<br />
Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service<br />
(Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.<br />
<br />
<service-group><br />
<name replace-wildcards="yes">srcpd on %h</name><br />
<service protocol="any"><br />
<type>_srcp._tcp</type><br />
<host-name>srcp.example.com</host-name><br />
<port>12345</port><br />
<txt-record>SRCP auf Mobaserver</txt-record><br />
</service><br />
</service-group><br />
<br />
==CRCF-Erweiterungen==<br />
<br />
Obwohl CRCF (Common Railroad Configuration Files) vor einigen Jahren einmal vorgeschlagen wurde, wurde es nicht angenommen, da es möglicherweise zu wenig Interessenten fand. Umso mehr Interessenten fanden sich nun in dieser Diskussion. Das deutet darauf hin, dass CRCF weiterhin ein Thema ist. Über die Idee von CRCF hinaus gab es einige weitgehendere Ideen dazu.<br />
<br />
<br />
===Anforderungen an CRCF===<br />
<br />
* Umständlich Eingabe von Informationen über Loks und Zubehör soll entfallen<br />
* Anlagenweite Anzeige von Klartextnamen anstatt von Adressen<br />
* Im Bezug auf den Server-Suchdienst könnte CRCF die Hostnamen (IP-Adressen) der SRCP-Server verwalten<br />
* Verwaltung statischer Informationen<br />
* Verwaltung dynamischer Informationen<br />
* CRCF in ausdruckbarer Form<br />
* Gliederung der CRCF<br />
* SRCP-Server sollten Zugriff auf die CRCF erhalten<br />
* Kommunikation zwischen Clients<br />
<br />
<br />
===Fragestellungen===<br />
<br />
* Wo soll die CRCF liegen?<br />
* Wie soll der Auskunftsdienst aussehen?<br />
* Wie sollen dynamische Informationen von der CRCF verwaltet werden?<br />
* Betrifft die Kommunikation zwischen Clients die CRCF?<br />
<br />
Folgendes Schema sollte als Grundlage für weitere Diskussionen dienen:<br />
<br />
(TODO: Abbildung)<br />
<br />
<br />
===Implementierungsvorschläge===<br />
<br />
====Datenablage gemäß CRCF Spezifikation 0.2.0====<br />
* basiert auf SRCP<br />
* physikalisch liegen die CRCF-Daten beim SRCP-Server<br />
* Auskunftdienst ist Bestandteil von SRCP (Befehl CONFGET)<br />
* ist praktisch auf SRCP 0.7.1 ausgerichtet, deswegen fehlen wichtige Details der 0.8.X-Welt, wie z.B. Busse<br />
* unterstützt die CRCF als textbasierte Dateien<br />
* Verwaltung der Daten in Sinne von SRCP -> d.h. Die einzelnen Datenfelder kommen aus der SRCP-Welt<br />
* hält ausschliesslich statische Daten bereit<br />
* enthält auch Daten über die Eigenschaften eines Servers<br />
* pro SRCP-Server eine CRCF<br />
<br />
====Datenablage bei einem spezialisierten SRCP-Client====<br />
* die CRCF-Daten liegen bei einem SRCP-Client<br />
* Anfragen an die CRCF erfolgen zunächst an den SRCP-Server, der die Daten an den spezialisierten Client weiterleitet<br />
* nutzt SRCP als Tunnel, da CRCF-Anfragen nur weitergeleitet werden<br />
* Auskunftsbefehl ist jedoch als SRCP-Kommando auszuführen<br />
* Durch das ungesehene Weiterleiten von Nachrichten durch den SRCP-Server wird eine Kommunikation zwischen Clients ermöglicht <br />
* der Client muss sich bei allen verfügbaren SRCP-Server anmelden, damit Daten anlagenweit verteilt werden können<br />
* Der Client kann dann konsistent statische und dynamische Daten verwalten<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* Verwaltung von Daten, die über die SRCP-Welt hinausgehen, beispielsweise die Verwaltung von Fahrstrassen und kompletten Layouts<br />
<br />
====Datenablage bei einem separaten CRCF-Server====<br />
* Auskunftsdienst muss als neues Protokoll implementiert werden<br />
* SRCP-Clients sowie SRCP-Server können anfragen<br />
* Verwaltung von rein statischen Daten<br />
* Falls zusätzlich zum Auskunftsdienst ein Meldedienst implementiert wird, können auch dynamische Daten verwaltet werden<br />
* Kommunikation zwischen Clients könnte mittels einer Mailboxfunktion möglich werden<br />
* das SRCP-Protokoll wird nicht geändert, CRCF existiert parallel<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* SRCP-Server können Meldungen an die CRCF senden, um deren Inhalt zu aktualisieren<br />
<br />
====Bereitstellung der CRCF-Daten via Zeroconf-Dienst====<br />
<br />
* ...<br />
<br />
===Erweiterung des bisherigen Befehlsvorrats===<br />
Der bisherige Namensraum von CRCF umfaßt keine Befehle, die Objekte einer höheren Abstraktionsebene beschreiben. Für die Attribute dieser makroskopischen Objekte gibt es ebenfalls noch keine Festlegung. Zum Teil sind die Werte dieser Attribute statisch zum Teil ändern sich sich während des Betriebs. Der Bedarf für folgende Begriffe ist vorhanden:<br />
<br />
; Stellwerk (RWCC, Railway Control Center)<br />
:: Steuerungsinstanz, die Fahrstraßen verwaltet, für ein oder mehrere Bahnhöfe zuständig ist, Zugmeldungen abwickelt, ihr zuständiges Streckennetz kennt, einzuhaltende Geschwindigkeiten überwacht und bei Überschreitungen eingreift etc.<br />
; Gleisbild (LAYOUT)<br />
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, etc.<br />
; Fahrstraße (ROUTE)<br />
:: Sicherheitstechnisch überwachter Streckenabschnitt innerhalb eines Stellwerks, der über Informationen zur Start- und Zielsignal, Soll-Weichenstellungen, Freimeldeabschnitte, Typinformation (für anzuwendenden Regelsatz), den aktuellen Zustand (eingestellt, aufgelöst, reserviert, teilaufgelöst) etc. verfügt.<br />
; Weichenstraße (?)<br />
:: Sammlung schaltbarer Magnetartikel und ihrer Sollstellungen ohne sicherheitstechnische Überwachung <br />
:: Anmerkung von svesch: Das ist meiner Meinung nach kein neues Objekt, das ist nur eine Liste von GAs.<br />
; Zugsteuerung (TNCC, Train Control Center)<br />
:: Instanz, die die Logistik eines gegebenen Vorrats an Zügen übernimmt z.B. fahrplangesteuerte Fahrten von Zügen zwischen Bahnhöfen<br />
; Zug (TRAIN)<br />
:: Instanz, die über ihre Zugnummer identifizierbar ist, eine oder mehrere Lokomotiven ansteuert, Informationen zu Typ und Länge verfügt etc.<br />
<br />
(TODO: weitere ergänzen)<br />
<br />
==SRCP-Erweiterungen==<br />
Der bisherige Umfang des SRCP-Protokolls definiert keine Möglichkeit, mit der SRCP-Clients untereinander direkt Informationen austauschen können. Ein Bedarf dafür ist jedoch durchaus gegeben, wie folgende Auflistung zeigt:<br />
<br />
* Zugmeldungen zwischen Stellwerken<br />
* Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)<br />
* Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung<br />
* Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware<br />
* Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz<br />
* Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation (FIXME: falsch einsortiert)<br />
<br />
Weiterhin ist es mit SRCP prinzipiell möglich, eine Modellbahnanlage über mehrere SRCP-Server zu bedienen, es gibt aber bisher kein Konzept, das einen Informationsübergang zwischen den Server-Bereichen erlaubt.<br />
<br />
Zur Realisierung dieser neu zu implementierenden Informationswege wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.<br />
<br />
<br />
===Neuer Befehl im Kommandomodus===<br />
====Bewertung des Vorschlags====<br />
<br />
Die Implementierung wird nicht weiterverfolgt, da der Vorschlag zur neuen Gerätegruppe besser ins bisherige SRCP paßt. Die hier andiskutierten CRCF-Nachrichten können mit dem anderen Vorschlag ebenfalls transportiert werden.<br />
<br />
====Vorschlag====<br />
Die aktuell SRCP-Spezifikation umfaßt für den Kommandomodus einen definierten Satz an Befehlen, die in der folgenden allgemeinen Syntax an den Server gesendet werden:<br />
<br />
<kommando> <kommandoparameter> <br />
<br />
Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:<br />
<br />
<kommando> <bus> <gerätegruppe> <parameter><br />
<br />
Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.<br />
<br />
Vom Server abgearbeitete Befehle werden an alle im Infomodus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ mit der folgenden allgemeinen Syntax weitergeleitet:<br />
<br />
<codenr> INFO <bus> <gerätegruppe> <parameter><br />
<br />
Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.<br />
<br />
Von dieser Situation ausgehend, kann ein neues Kommando ergänzt werden, dass von SRCP-Server selbst nur zum Weiterleiten einer Nachricht an die angeschlossenen SRCP-Clients genutzt wird. Den Inhalt der Nachricht muß der SRCP-Server nicht interpretieren. Die Form der Nachricht kann/soll/muß den gängigen SRCP-Konventionen bezüglich Zeichensatz, Länge etc. genügen.<br />
<br />
Ein erster (anarchischer) Ansatz könte in SRCP 0.8-Terminologie so aussehen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
ECHO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 ECHO <message><br />
<br />
Einzweiter, mehr geordneter Ansatz, schreibt die Verwendung definierter Befehle (SRCP-Makros) vor, analog also beispielsweise so:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
MACRO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 MACRO <message><br />
<br />
Wobei <message> diesmal eine Folge von definierten (genormten) Befehlen inklusive deren Wert-Parametern sein muß. Diese Makros müssen natürlich den Kommunikationsbedarf der Clients (Frage/Antwort-Spiele) abdecken.<br />
<br />
Der dritte Ansatz wäre, statt der neu zu erfindenden Makros, CRCF zu benutzen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
CRCF 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 CRCF <message><br />
<br />
Der Inhalt von <message> wäre dann eine CRCF-Befehlsfolge.<br />
<br />
Angenommen eine Ablaufsteuerung (als eigener SRCP-Client) möchte eine Fahrstraße einstellen, dann sendet er an das zuständige Stellwerk folgende (CRCF-)Befehlsfolge:<br />
<br />
ROUTE <routeid> SET STATE 1<br />
<br />
Den Erfolg bekommt er dann vom Stellwerk zurückgemeldet oder kann ihn auch abfragen z.B. gemäß:<br />
<br />
ROUTE <routeid> GET STATE<br />
<br />
Den Bedarf, dass ein SRCP-Client einem Stellwerk Daten zur Konfiguration von Fahrstraßen sendet, wäre prinzipiell auch möglich:<br />
<br />
ROUTE <routeid> ADD GA <busid> <address> <port> <state><br />
<br />
Oder entfernen:<br />
<br />
ROUTE <routeid> REMOVE GA <busid> <address><br />
<br />
Um eine Client-Client-Verbindung zu unterhalten, müßte der Sender eines CRCF-Befehls seine<br />
SRCP-Session-ID immer mitsenden, dann könnte die Antwort zielgerichtet erfolgen:<br />
<br />
CRCF 0 <sender-sessionid> <empfänger-sessionid> <CRCF-message><br />
<br />
Mit dem Inhalt von <sessionid> ließe sich ein CRCF-Broadcast einfach von einer Punkt-zu-Punkt-Verbindung unterscheiden:<br />
<br />
# Der Wert ist 0: Broadcast<br />
# Der Wert ist >0: Punkt-zu-Punkt-Verbindung<br />
<br />
Auch das Thema "Zugbeeinflussung" läßt sich hiermit darstellen. Ein Zug muß während seiner Fahrt Geschwindigkeitsregeln einhalten, die das Stellwerk überwacht. Bei Überschreitungen sendet das Stellwerk einen Abbremsbefehl:<br />
<br />
CRCF 0 <sender-session-id> 0 TRAIN <train-id> SPEED SET 0<br />
<br />
===Neuer Sitzungstyp===<br />
<br />
====Bewertung====<br />
<br />
Die Diskussion dauert noch an, daher ist keine abschliessende Bewertung möglich.<br />
<br />
====Vorschlagstext====<br />
<br />
Eigene CRCF-Sitzungen trennen sowohl den Namensraum von SRCP und CRCF als auch den durch beide Kommunikationsformen entstehenden Netzwerkverkehr:<br />
<br />
SET PROTOCOL CRCF 0.3<br />
SET CONNECTIONMODE CRCF INFO|COMMAND<br />
<br />
Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig. Alternativ ist ein Systemdienst möglich, der nur CRCF-Sitzungen, aber keine SRCP-Sitzungen unterstütz.<br />
<br />
(TODO: weitere Ausführung)<br />
<br />
===Neue Gerätegruppe===<br />
<br />
====Bewertung====<br />
<br />
Allgemein nutzbare Kommunikationsstrecke. SRCP muß um einige<br />
Details erweitert werden (siehe unten). Es entsteht ein permanenter<br />
Pflegedienst für Vergabe der Messagetypen (kann automatisiert werden)<br />
<br />
====Vorschlagstext====<br />
<br />
Für den generalisierten Messageaustausch wird eine neue Devicegruppe eingerichtet:<br />
<br />
GM Generic Message<br />
<br />
Die einzige (sinnvoll) anzuwendende Methode ist SET.<br />
Im SRCP ist noch festzulegen, das eine Busnummer nicht als<br />
SessionID vergeben werden darf.<br />
<br />
Im Kommandomodus:<br />
<br />
SET <EmpfängerID> GM <AntwortID> <messagetype> <messagetext><br />
<br />
EmpfängerID ist die Busnummer oder SessionID, die die Message<br />
erhalten soll. Ist diese 0, so wird die Message als Broadcast an<br />
alle INFO Sessions gesendet. Die AntwortID ist die SessionID (oder<br />
0) der INFO Session, an die eine evt. Antwortmessage gesendet<br />
werden soll.<br />
<br />
Im INFO Modus:<br />
<br />
INFO <EmpfängerID> GM <AntwortID> <messagetype> <messagetext><br />
<br />
<br />
Für <messagetext> gelten die im SRCP üblichen Einschränkungen:<br />
*keine Leerzeichen (kann man durch Konvention z.B. durch URL Codierung umgehen).<br />
*maximale Zeilenlänge 1000 Zeichen (inkl. der Befehle & CRLF).<br />
<br />
<messagetype> ist ein zentral gepflegte Liste von Clientidentifiern um den Messagetyp erkennen zu können.<br />
<br />
Beispiel: Ein Client fragt nach den Einzelheiten des Gerätes GA 1 auf<br />
Bus 17. (Schritt A)<br />
<br />
SET 0 GM 45 CRCF CONFGET 17 GA 1<br />
<br />
Wie der INFO aussieht, dürfte offensichtlich sein. Er geht an alle INFO Sessions.<br />
(Schritt B)<br />
<br />
INFO 0 GM 45 CRCF CONFGET 17 GA 1<br />
<br />
<br />
Wenn ein CRCF Service diese Message erhalten hat, sendet er eine<br />
passende Antwort an den SRCP Server (Schritt C)<br />
<br />
SET 45 GM 25 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Die Infosession des CRCF Services ist im Beispiel 25, die Antwort wird vom<br />
SRCP Server direkt an die SESSION 45 weitergeleitet.<br />
<br />
INFO 45 GM 25 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Der Nachrichtenfluß ist im Bild dargestellt. CA ist die Command Session von<br />
Client A, IA die Infosession. Client B (CRCF Server analog)<br />
[[Bild:SRCP_GM.png]]</div>Stefan Bormannhttp://der-moba.de/index.php?title=LocoNet&diff=11893LocoNet2007-01-24T21:36:20Z<p>Stefan Bormann: /* Nachteile/Einschränkungen */</p>
<hr />
<div>LocoNet ist ein Peer-to-Peer Netzwerk, dass von der Firma [http://www.digitrax.com Digitrax] für Modellbahnanlagen konzipiert wurde. Das LocoNet dient sozusagen als Transportmedium innerhalb der Modellbahn, das einen gleichberechtigten Zugriff aller LocoNet-kompatiblen Komponenten in beiden Richtungen zulässt. Darüber kommunizieren die Zentrale, die Handregler; ebenso Schaltdecoder, Belegtmelder, Booster und angeschlossene Computer. Die Regler sind über LocoNet mit der Zentrale verbunden, diese wiederum steuert über dasselbe Netz die Booster, über die letztendlich die Decoder in der Lok ihre Steuersignale erhalten. Die in LocoNet enthaltenen Strukturen (Protokolle) sind ähnlich in der Datenkommunikation zu finden; LocoNet arbeitet nach dem [http://de.wikipedia.org/wiki/CSMA/CD CSMA/CD] bzw. [http://de.wikipedia.org/wiki/CSMA/CA CSMA/CA] Zugriffsverfahren. Die genaue technische Spezifikation von LocoNet gibt es bei Digitrax unter:<br />
http://www.digitrax.com/ftp/loconetpersonaledition.pdf<br />
<br />
==Vorteile==<br />
* Verbindung aller Komponenten über ein einfaches, preiswertes Steckersystem (RJ12-Würfelstecker)<br />
* Die Kabel können ausreichende Längen haben und auf der Anlage in Stern- oder Busform verteilt sein.<br />
* Flexibles Design: Jedes Gerät darf senden, was er will, solange es nicht mit bestehendem Traffik kollidiert - somit auch Inhalte und sogar Formate (ggf. mit variabler Nutzdatenlänge), die sich der Erfinder des LN nicht ausgedacht hat.<br />
* Die Buslast hängt von der Anzahl der Änderungen ab, nicht von der Anzahl der Geräte, die ggf. nichts tun<br />
* Keine niedrige harte Grenze in der Adressierung<br />
<br />
==Nachteile/Einschränkungen==<br />
* Kein '''echtes''' Echtzeitsystem<br />
* Begrenzung auf 119 verwaltete Lokadressen<br />
<br />
[[Kategorie:Digitalbetrieb]]</div>Stefan Bormannhttp://der-moba.de/index.php?title=Benutzer:Stefan_Bormann&diff=11892Benutzer:Stefan Bormann2007-01-24T21:32:21Z<p>Stefan Bormann: </p>
<hr />
<div>Meine modellbahnerischen Träume lebe ich im [[FREMO]] aus.<br />
Meinen Schwerpunkt lege ich auf [[Eisenbahnsicherungs- und -signaltechnik]] und [[DCC]] zur Loksteuerung, beides gerne zusammen mit [[LocoNet]].<br />
Wer noch mehr über mich wissen möchte, schaut auf meiner [http://www.nord-com.net/stefan.bormann Homepage] nach.</div>Stefan Bormannhttp://der-moba.de/index.php?title=SRCP-Erweiterungen&diff=11891SRCP-Erweiterungen2007-01-24T21:16:21Z<p>Stefan Bormann: /* Bewertung */</p>
<hr />
<div>==Das initiale Posting==<br />
<br />
Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.<br />
<br />
Hier der initiale Eintrag:<br />
<br />
Hallo SRCP-Fans!<br />
<br />
ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich<br />
aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das<br />
mein erster Eintrag in der Gruppe ;).<br />
Während der Entwicklung kamen einige Ideen, die ich nun hier zur<br />
Diskussion stellen möchte:<br />
<br />
# Ich hätte gern einen Dienst für Clients, mit dem sie den Server (bzw. dessen IP-Adresse) finden können. Da gibt es sicher mehrere Möglichkeiten, ich dachte an Broadcast oder an eine DHCP-Option.<br />
# Stichwort CRCF: Was ist mit der Entwicklung? Ich hätte gern dieses Feature für SRCP und würde mich ggf. an der Mitentwicklung beteiligen.<br />
<br />
Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art<br />
Stammtisch?<br />
<br />
Gruß, Sven.<br />
<br />
Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.<br />
<br />
<br />
==SRCP-Server-Suchdienst==<br />
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ Zeroconf]-Systemdienst (DNS-SD/mDNS) einzusetzen. Dieser ermöglicht die Suche bzw. das Veröffentlichen beliebiger Systemdiente durch das Versenden eines ServiceDiscovery-Multicasts. Es existieren hierfür derzeit zwei zueinander kompatible Implementierungen, die beide als OpenSource freigegeben sind:<br />
<br />
* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.<br />
* [http://avahi.org/ Avahi], als praktisch schon etablierter Standard für Linux.<br />
<br />
Unter anderem ist es hiermit möglich, Angaben über die Portnummer zu veröffentlichen, auf der der Server seinen Dienst anbietet. Da es für das SRCP-Protokoll noch keine offiziell über [http://www.iana.org/ IANA/IETF] reservierte Portnummer gibt, hat ein SRCP-Administrator problemlos die Freiheit, einen von der aktuellen SRCP-Spezifikation abweichenden Wert zu wählen. Auch die Anzahl der in einem Netz betriebenen SRCP-Server ist damit nicht eingeschränkt.<br />
<br />
Dem Administrator eines SRCP-Servers bleibt es überlassen, auf dem gleichen Rechner auch einen „Zeroconf“-Systemdienst einzurichten. Er muß, wenn er auf seiner Modellbahn entsprechende SRCP-Clients benutzen möchte, das Programm installieren und so konfigurieren, dass der SRCP-Dienst veröffentlicht wird. Alternativ kann ein SRCP-Server sich auch automatisiert beim Zeroconf-Dienst anmelden. Die eigentliche Arbeit für die Nutzung des SD-Dienstes liegt beim Entwickler des „Einsteck-und-Spiel“-SRCP-Clients, denn dieser SRCP-Client muß nicht nur SRCP sprechen, sondern auch noch ein DNS-SD/mDNS-Client sein.<br />
<br />
Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service<br />
(Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.<br />
<br />
<service-group><br />
<name replace-wildcards="yes">srcpd on %h</name><br />
<service protocol="any"><br />
<type>_srcp._tcp</type><br />
<host-name>srcp.example.com</host-name><br />
<port>12345</port><br />
<txt-record>SRCP auf Mobaserver</txt-record><br />
</service><br />
</service-group><br />
<br />
==CRCF-Erweiterungen==<br />
<br />
Obwohl CRCF (Common Railroad Configuration Files) vor einigen Jahren einmal vorgeschlagen wurde, wurde es nicht angenommen, da es möglicherweise zu wenig Interessenten fand. Umso mehr Interessenten fanden sich nun in dieser Diskussion. Das deutet darauf hin, dass CRCF weiterhin ein Thema ist. Über die Idee von CRCF hinaus gab es einige weitgehendere Ideen dazu.<br />
<br />
<br />
===Anforderungen an CRCF===<br />
<br />
* Umständlich Eingabe von Informationen über Loks und Zubehör soll entfallen<br />
* Anlagenweite Anzeige von Klartextnamen anstatt von Adressen<br />
* Im Bezug auf den Server-Suchdienst könnte CRCF die Hostnamen (IP-Adressen) der SRCP-Server verwalten<br />
* Verwaltung statischer Informationen<br />
* Verwaltung dynamischer Informationen<br />
* CRCF in ausdruckbarer Form<br />
* Gliederung der CRCF<br />
* SRCP-Server sollten Zugriff auf die CRCF erhalten<br />
* Kommunikation zwischen Clients<br />
<br />
<br />
===Fragestellungen===<br />
<br />
* Wo soll die CRCF liegen?<br />
* Wie soll der Auskunftsdienst aussehen?<br />
* Wie sollen dynamische Informationen von der CRCF verwaltet werden?<br />
* Betrifft die Kommunikation zwischen Clients die CRCF?<br />
<br />
Folgendes Schema sollte als Grundlage für weitere Diskussionen dienen:<br />
<br />
(TODO: Abbildung)<br />
<br />
<br />
===Implementierungsvorschläge===<br />
<br />
====Datenablage gemäß CRCF Spezifikation 0.2.0====<br />
* basiert auf SRCP<br />
* physikalisch liegen die CRCF-Daten beim SRCP-Server<br />
* Auskunftdienst ist Bestandteil von SRCP (Befehl CONFGET)<br />
* ist praktisch auf SRCP 0.7.1 ausgerichtet, deswegen fehlen wichtige Details der 0.8.X-Welt, wie z.B. Busse<br />
* unterstützt die CRCF als textbasierte Dateien<br />
* Verwaltung der Daten in Sinne von SRCP -> d.h. Die einzelnen Datenfelder kommen aus der SRCP-Welt<br />
* hält ausschliesslich statische Daten bereit<br />
* enthält auch Daten über die Eigenschaften eines Servers<br />
* pro SRCP-Server eine CRCF<br />
<br />
====Datenablage bei einem spezialisierten SRCP-Client====<br />
* die CRCF-Daten liegen bei einem SRCP-Client<br />
* Anfragen an die CRCF erfolgen zunächst an den SRCP-Server, der die Daten an den spezialisierten Client weiterleitet<br />
* nutzt SRCP als Tunnel, da CRCF-Anfragen nur weitergeleitet werden<br />
* Auskunftsbefehl ist jedoch als SRCP-Kommando auszuführen<br />
* Durch das ungesehene Weiterleiten von Nachrichten durch den SRCP-Server wird eine Kommunikation zwischen Clients ermöglicht <br />
* der Client muss sich bei allen verfügbaren SRCP-Server anmelden, damit Daten anlagenweit verteilt werden können<br />
* Der Client kann dann konsistent statische und dynamische Daten verwalten<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* Verwaltung von Daten, die über die SRCP-Welt hinausgehen, beispielsweise die Verwaltung von Fahrstrassen und kompletten Layouts<br />
<br />
====Datenablage bei einem separaten CRCF-Server====<br />
* Auskunftsdienst muss als neues Protokoll implementiert werden<br />
* SRCP-Clients sowie SRCP-Server können anfragen<br />
* Verwaltung von rein statischen Daten<br />
* Falls zusätzlich zum Auskunftsdienst ein Meldedienst implementiert wird, können auch dynamische Daten verwaltet werden<br />
* Kommunikation zwischen Clients könnte mittels einer Mailboxfunktion möglich werden<br />
* das SRCP-Protokoll wird nicht geändert, CRCF existiert parallel<br />
* SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen<br />
* SRCP-Server können Meldungen an die CRCF senden, um deren Inhalt zu aktualisieren<br />
<br />
====Bereitstellung der CRCF-Daten via Zeroconf-Dienst====<br />
<br />
* ...<br />
<br />
===Erweiterung des bisherigen Befehlsvorrats===<br />
Der bisherige Namensraum von CRCF umfaßt keine Befehle, die Objekte einer höheren Abstraktionsebene beschreiben. Für die Attribute dieser makroskopischen Objekte gibt es ebenfalls noch keine Festlegung. Zum Teil sind die Werte dieser Attribute statisch zum Teil ändern sich sich während des Betriebs. Der Bedarf für folgende Begriffe ist vorhanden:<br />
<br />
; Stellwerk (RWCC, Railway Control Center)<br />
:: Steuerungsinstanz, die Fahrstraßen verwaltet, für ein oder mehrere Bahnhöfe zuständig ist, Zugmeldungen abwickelt, ihr zuständiges Streckennetz kennt, einzuhaltende Geschwindigkeiten überwacht und bei Überschreitungen eingreift etc.<br />
; Gleisbild (LAYOUT)<br />
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, etc.<br />
; Fahrstraße (ROUTE)<br />
:: Sicherheitstechnisch überwachter Streckenabschnitt innerhalb eines Stellwerks, der über Informationen zur Start- und Zielsignal, Soll-Weichenstellungen, Freimeldeabschnitte, Typinformation (für anzuwendenden Regelsatz), den aktuellen Zustand (eingestellt, aufgelöst, reserviert, teilaufgelöst) etc. verfügt.<br />
; Weichenstraße (?)<br />
:: Sammlung schaltbarer Magnetartikel und ihrer Sollstellungen ohne sicherheitstechnische Überwachung <br />
:: Anmerkung von svesch: Das ist meiner Meinung nach kein neues Objekt, das ist nur eine Liste von GAs.<br />
; Zugsteuerung (TNCC, Train Control Center)<br />
:: Instanz, die die Logistik eines gegebenen Vorrats an Zügen übernimmt z.B. fahrplangesteuerte Fahrten von Zügen zwischen Bahnhöfen<br />
; Zug (TRAIN)<br />
:: Instanz, die über ihre Zugnummer identifizierbar ist, eine oder mehrere Lokomotiven ansteuert, Informationen zu Typ und Länge verfügt etc.<br />
<br />
(TODO: weitere ergänzen)<br />
<br />
==SRCP-Erweiterungen==<br />
Der bisherige Umfang des SRCP-Protokolls definiert keine Möglichkeit, mit der SRCP-Clients untereinander direkt Informationen austauschen können. Ein Bedarf dafür ist jedoch durchaus gegeben, wie folgende Auflistung zeigt:<br />
<br />
* Zugmeldungen zwischen Stellwerken<br />
* Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)<br />
* Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung<br />
* Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware<br />
* Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz<br />
* Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation (FIXME: falsch einsortiert)<br />
<br />
Weiterhin ist es mit SRCP prinzipiell möglich, eine Modellbahnanlage über mehrere SRCP-Server zu bedienen, es gibt aber bisher kein Konzept, das einen Informationsübergang zwischen den Server-Bereichen erlaubt.<br />
<br />
Zur Realisierung dieser neu zu implementierenden Informationswege wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.<br />
<br />
<br />
===Neuer Befehl im Kommandomodus===<br />
====Bewertung des Vorschlags====<br />
<br />
Die Implementierung wird nicht weiterverfolgt, da der Vorschlag zur neuen Gerätegruppe besser ins bisherige SRCP paßt. Die hier andiskutierten CRCF-Nachrichten können mit dem anderen Vorschlag ebenfalls transportiert werden.<br />
<br />
====Vorschlag====<br />
Die aktuell SRCP-Spezifikation umfaßt für den Kommandomodus einen definierten Satz an Befehlen, die in der folgenden allgemeinen Syntax an den Server gesendet werden:<br />
<br />
<kommando> <kommandoparameter> <br />
<br />
Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:<br />
<br />
<kommando> <bus> <gerätegruppe> <parameter><br />
<br />
Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.<br />
<br />
Vom Server abgearbeitete Befehle werden an alle im Infomodus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ mit der folgenden allgemeinen Syntax weitergeleitet:<br />
<br />
<codenr> INFO <bus> <gerätegruppe> <parameter><br />
<br />
Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.<br />
<br />
Von dieser Situation ausgehend, kann ein neues Kommando ergänzt werden, dass von SRCP-Server selbst nur zum Weiterleiten einer Nachricht an die angeschlossenen SRCP-Clients genutzt wird. Den Inhalt der Nachricht muß der SRCP-Server nicht interpretieren. Die Form der Nachricht kann/soll/muß den gängigen SRCP-Konventionen bezüglich Zeichensatz, Länge etc. genügen.<br />
<br />
Ein erster (anarchischer) Ansatz könte in SRCP 0.8-Terminologie so aussehen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
ECHO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 ECHO <message><br />
<br />
Einzweiter, mehr geordneter Ansatz, schreibt die Verwendung definierter Befehle (SRCP-Makros) vor, analog also beispielsweise so:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
MACRO 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 MACRO <message><br />
<br />
Wobei <message> diesmal eine Folge von definierten (genormten) Befehlen inklusive deren Wert-Parametern sein muß. Diese Makros müssen natürlich den Kommunikationsbedarf der Clients (Frage/Antwort-Spiele) abdecken.<br />
<br />
Der dritte Ansatz wäre, statt der neu zu erfindenden Makros, CRCF zu benutzen:<br />
<br />
Im Kommando-Modus verbundender Client:<br />
<br />
CRCF 0 <message><br />
<br />
Darauf der SRCP-Server an alle verbundenen Clients:<br />
<br />
<timestamp> <codenr> INFO 0 CRCF <message><br />
<br />
Der Inhalt von <message> wäre dann eine CRCF-Befehlsfolge.<br />
<br />
Angenommen eine Ablaufsteuerung (als eigener SRCP-Client) möchte eine Fahrstraße einstellen, dann sendet er an das zuständige Stellwerk folgende (CRCF-)Befehlsfolge:<br />
<br />
ROUTE <routeid> SET STATE 1<br />
<br />
Den Erfolg bekommt er dann vom Stellwerk zurückgemeldet oder kann ihn auch abfragen z.B. gemäß:<br />
<br />
ROUTE <routeid> GET STATE<br />
<br />
Den Bedarf, dass ein SRCP-Client einem Stellwerk Daten zur Konfiguration von Fahrstraßen sendet, wäre prinzipiell auch möglich:<br />
<br />
ROUTE <routeid> ADD GA <busid> <address> <port> <state><br />
<br />
Oder entfernen:<br />
<br />
ROUTE <routeid> REMOVE GA <busid> <address><br />
<br />
Um eine Client-Client-Verbindung zu unterhalten, müßte der Sender eines CRCF-Befehls seine<br />
SRCP-Session-ID immer mitsenden, dann könnte die Antwort zielgerichtet erfolgen:<br />
<br />
CRCF 0 <sender-sessionid> <empfänger-sessionid> <CRCF-message><br />
<br />
Mit dem Inhalt von <sessionid> ließe sich ein CRCF-Broadcast einfach von einer Punkt-zu-Punkt-Verbindung unterscheiden:<br />
<br />
# Der Wert ist 0: Broadcast<br />
# Der Wert ist >0: Punkt-zu-Punkt-Verbindung<br />
<br />
Auch das Thema "Zugbeeinflussung" läßt sich hiermit darstellen. Ein Zug muß während seiner Fahrt Geschwindigkeitsregeln einhalten, die das Stellwerk überwacht. Bei Überschreitungen sendet das Stellwerk einen Abbremsbefehl:<br />
<br />
CRCF 0 <sender-session-id> 0 TRAIN <train-id> SPEED SET 0<br />
<br />
===Neuer Sitzungstyp===<br />
<br />
====Bewertung====<br />
<br />
Die Implementationen von CRCF und SRCP werden komplett getrennt.<br />
<br />
Vorteile/Gründe:<br />
* Ermöglicht Kapselung von unterschiedlichern Client-Funktionalitäten: SRCP und CRCF sind für komplett unterschiedliche Zwecke gedacht, SRCP dient der Kommunikation mit der Modellbahn-Hardware, CRCF dient der Kommunikation der Clients untereinander.<br />
* Dies senkt die Anforderungen an einen reinen SRCP-Server<br />
* Es erspart mobilen Eingabegeräten z.B. einem Handregler den extremen Traffic, den intelligentere stationäre Clients untereinander haben.<br />
<br />
Der Programmieraufwand zur Unterhaltung der zusätzlichen Netzwerkverbindungen sollte sich nicht unterscheiden, da fuer SRCP alleine auch schon mehr als eine TCP-Verbindung nötig ist.<br />
<br />
====Vorschlagstext====<br />
<br />
Eigene CRCF-Sitzungen trennen sowohl den Namensraum von SRCP und CRCF als auch den durch beide Kommunikationsformen entstehenden Netzwerkverkehr:<br />
<br />
SET PROTOCOL CRCF 0.3<br />
SET CONNECTIONMODE CRCF INFO|COMMAND<br />
<br />
Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig. Alternativ ist ein Systemdienst möglich, der nur CRCF-Sitzungen, aber keine SRCP-Sitzungen unterstütz.<br />
<br />
(TODO: weitere Ausführung)<br />
<br />
===Neue Gerätegruppe===<br />
<br />
====Bewertung====<br />
<br />
Allgemein nutzbare Kommunikationsstrecke. SRCP muß um einige<br />
Details erweitert werden (siehe unten). Es entsteht ein permanenter<br />
Pflegedienst für Vergabe der Messagetypen (kann automatisiert werden)<br />
<br />
====Vorschlagstext====<br />
<br />
Für den generalisierten Messageaustausch wird eine neue Devicegruppe eingerichtet:<br />
<br />
GM Generic Message<br />
<br />
Die einzige (sinnvoll) anzuwendende Methode ist SET.<br />
Im SRCP ist noch festzulegen, das eine Busnummer nicht als<br />
SessionID vergeben werden darf.<br />
<br />
Im Kommandomodus:<br />
<br />
SET <EmpfängerID> GM <AntwortID> <messagetype> <messagetext><br />
<br />
EmpfängerID ist die Busnummer oder SessionID, die die Message<br />
erhalten soll. Ist diese 0, so wird die Message als Broadcast an<br />
alle INFO Sessions gesendet. Die AntwortID ist die SessionID (oder<br />
0) der INFO Session, an die eine evt. Antwortmessage gesendet<br />
werden soll.<br />
<br />
Im INFO Modus:<br />
<br />
INFO <EmpfängerID> GM <AntwortID> <messagetype> <messagetext><br />
<br />
<br />
Für <messagetext> gelten die im SRCP üblichen Einschränkungen:<br />
*keine Leerzeichen (kann man durch Konvention z.B. durch URL Codierung umgehen).<br />
*maximale Zeilenlänge 1000 Zeichen (inkl. der Befehle & CRLF).<br />
<br />
<messagetype> ist ein zentral gepflegte Liste von Clientidentifiern um den Messagetyp erkennen zu können.<br />
<br />
Beispiel: Ein Client fragt nach den Einzelheiten des Gerätes GA 1 auf<br />
Bus 17. (Schritt A)<br />
<br />
SET 0 GM 45 CRCF CONFGET 17 GA 1<br />
<br />
Wie der INFO aussieht, dürfte offensichtlich sein. Er geht an alle INFO Sessions.<br />
(Schritt B)<br />
<br />
INFO 0 GM 45 CRCF CONFGET 17 GA 1<br />
<br />
<br />
Wenn ein CRCF Service diese Message erhalten hat, sendet er eine<br />
passende Antwort an den SRCP Server (Schritt C)<br />
<br />
SET 45 GM 25 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Die Infosession des CRCF Services ist im Beispiel 25, die Antwort wird vom<br />
SRCP Server direkt an die SESSION 45 weitergeleitet.<br />
<br />
INFO 45 GM 25 CRCF CONFINFO 17 GA 1 ....<br />
<br />
Der Nachrichtenfluß ist im Bild dargestellt. CA ist die Command Session von<br />
Client A, IA die Infosession. Client B (CRCF Server analog)<br />
[[Bild:SRCP_GM.png]]</div>Stefan Bormann