SRCP-Erweiterungen: Unterschied zwischen den Versionen

Version vom 19. Januar 2007, 08:29 Uhr

Das initiale Posting

Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.

Hier der initiale Eintrag:

Hallo SRCP-Fans!

ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das mein erster Eintrag in der Gruppe ;). Während der Entwicklung kamen einige Ideen, die ich nun hier zur Diskussion stellen möchte:

1. 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.
2. 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.

Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art Stammtisch?

Gruß, Sven.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

SRCP-Server-Suchdienst

Sehr schnell kam der Vorschlag, für diesen Bedarf einen 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:

• Bonjour, von Apple für Mac, UNIXoide-Systeme und Windows.
• Avahi, als praktisch schon etablierter Standard für Linux.

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 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.

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. 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.

Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service (Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.

<service-group>
   <name replace-wildcards="yes">srcpd on %h</name>
   <service protocol="any">
       <type>_srcp._tcp</type>
       <host-name>srcp.example.com</host-name>
       <port>12345</port>
       <txt-record>SRCP auf Mobaserver</txt-record>
   </service>
</service-group>

CRCF-Erweiterungen

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.

Anforderungen an CRCF

• Umständlich Eingabe von Informationen über Loks und Zubehör soll entfallen
• Anlagenweite Anzeige von Klartextnamen anstatt von Adressen
• Im Bezug auf den Server-Suchdienst könnte CRCF die Hostnamen (IP-Adressen) der SRCP-Server verwalten
• Verwaltung statischer Informationen
• Verwaltung dynamischer Informationen
• CRCF in ausdruckbarer Form
• Gliederung der CRCF
• SRCP-Server sollten Zugriff auf die CRCF erhalten
• Kommunikation zwischen Clients

Fragestellungen

• Wo soll die CRCF liegen?
• Wie soll der Auskunftsdienst aussehen?
• Wie sollen dynamische Informationen von der CRCF verwaltet werden?
• Betrifft die Kommunikation zwischen Clients die CRCF?

Folgendes Schema sollte als Grundlage für weitere Diskussionen dienen:

(TODO: Abbildung)

Implementierungsvorschläge

Implementierung nach CRCF Spezifikation 0.2.0

• basiert auf SRCP
• physikalisch liegen die CRCF-Daten beim SRCP-Server
• Auskunftdienst ist Bestandteil von SRCP (Befehl CONFGET)
• ist praktisch auf SRCP 0.7.1 ausgerichtet, deswegen fehlen wichtige Details der 0.8.X-Welt, wie z.B. Busse
• unterstützt die CRCF als textbasierte Dateien
• Verwaltung der Daten in Sinne von SRCP -> d.h. Die einzelnen Datenfelder kommen aus der SRCP-Welt
• hält ausschliesslich statische Daten bereit
• enthält auch Daten über die Eigenschaften eines Servers
• pro SRCP-Server eine CRCF

Implementierung als spezialisierter SRCP-Client

• die CRCF-Daten liegen bei einem SRCP-Client
• Anfragen an die CRCF erfolgen zunächst an den SRCP-Server, der die Daten an den spezialisierten Client weiterleitet
• nutzt SRCP als Tunnel, da CRCF-Anfragen nur weitergeleitet werden
• Auskunftsbefehl ist jedoch als SRCP-Kommando auszuführen
• Durch das ungesehene Weiterleiten von Nachrichten durch den SRCP-Server wird eine Kommunikation zwischen Clients ermöglicht
• der Client muss sich bei allen verfügbaren SRCP-Server anmelden, damit Daten anlagenweit verteilt werden können
• Der Client kann dann konsistent statische und dynamische Daten verwalten
• SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen
• Verwaltung von Daten, die über die SRCP-Welt hinausgehen, beispielsweise die Verwaltung von Fahrstrassen und kompletten Layouts

Implementierung als separater Server

• Auskunftsdienst muss als neues Protokoll implementiert werden
• SRCP-Clients sowie SRCP-Server können anfragen
• Verwaltung von rein statischen Daten
• Falls zusätzlich zum Auskunftsdienst ein Meldedienst implementiert wird, können auch dynamische Daten verwaltet werden
• Kommunikation zwischen Clients könnte mittels einer Mailboxfunktion möglich werden
• das SRCP-Protokoll wird nicht geändert, CRCF existiert parallel
• SRCP-Server haben die Möglichkeit an Informationen von CRCF zu gelangen
• SRCP-Server können Meldungen an die CRCF senden, um deren Inhalt zu aktualisieren

Bereitstellung der CRCF-Daten via Zeroconf-Dienst

• ...

SRCP-Erweiterungen

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:

• Zugmeldungen zwischen Stellwerken
• Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)
• Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung
• Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware
• Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz
• Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation

Zur Realisierung dieses neu zu implementierenden Informationsweges wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.

Neuer Befehl im Kommandomodus

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:

<kommando> <kommandoparameter> 

Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:

<kommando> <bus> <gerätegruppe> <parameter>

Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.

Vom Server abgearbeitete Befehle werden an alle im Infomodus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ mit der folgenden allgemeinen Syntax weitergeleitet:

<codenr> INFO <bus> <gerätegruppe> <parameter>

Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.

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.

(TODO: Weitere Ausführung)

Neuer Sitzungstyp (Modus)

Eigene CRCF Sessions:

SET PROTOCOL CRCF 0.3
SET CONNECTIONMODE CRCF INFO|COMMAND

Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig.

(TODO: weitere Ausführung)

Neue Gerätegruppe

Für den generalisierten Messageaustausch wird eine neue Devicegruppe eingerichtet:

GM Generic Message

Sie ist ähnlich wie das TIME Device nur auf Bus 0 zulässig. Die einzige (sinnvoll) anzuwendende Methode ist SET.

Im Kommandomodus:

SET 0 GM <messagetype> <messagetext>

Im INFO Modus:

INFO 0 GM <sessionid> <messagetype> <messagetext>

Für <messagetext> gelten die im SRCP üblichen Einschränkungen:

• keine Leerzeichen (kann man durch Konvention z.B. durch URL Codierung umgehen).
• maximale Zeilenlänge 1000 Zeichen (inkl. der Befehle & CRLF).

<messagetype> ist ein zentral gepflegte Liste von Clientidentifiern um den Messagetyp erkennen zu können.

Beispiel (willkürlich):

SET 0 GM STELLWERK_ABC_V1 ZUG0815_LOSGEFAHREN

Wie der INFO aussieht, dürfte offensichtlich sein. Er geht an alle INFO Sessions.

(TODO: Ausführung der Konsequenzen)