SRCP-Grundlagen

SRCP-Spezifikation

Die aktuelle SRCP-Spezifikation hat die Version 0.8.3 (HTML, PDF). SRCP 0.8.x ist inkompatibel zu früheren SRCP-Versionen. Bereits vorhandene Software für SRCP 0.7.x wird im Laufe der Zeit auf SRCP 0.8.x umgestellt.

Historische Spezifikationsversionen

• SRCP - Simple Railroad Command Protocol 0.5.0
• SRCP - Simple Railroad Command Protocol 0.6.0
• SRCP - Simple Railroad Command Protocol 0.6.1
• SRCP - Simple Railroad Command Protocol 0.7.0
• SRCP - Simple Railroad Command Protocol 0.7.2
• SRCP - Simple Railroad Command Protocol 0.7.3
• SRCP - Simple Railroad Command Protocol 0.8.0

Designprinzipien

SRCP benutzt zeilenorientierten Klartext. Der Text besteht aus Kommandos und Informationen. Kommandos werden vom Client an den Server übermittelt, Informationen vom Server an den Client. Jedes Kommando und jede Information besteht aus exakt einer Zeile. Es ist eine maximale Zeilenlänge definiert, um auch Programmieranfängern einfache Fehler wie Pufferüberläufe (Buffer Overflows) vermeiden zu helfen.

Der Server stellt seine Dienste im Netzwerk bereit. Zur Verbindungsaufnahme sind sein Hostname (ersatzweise die IP-Adresse) und der Netzwerkport (z.B. 4303) bei jedem Client anzugeben. Der Client kann diese Angaben über andere Dienste anfordern (Bonjour, Zeroconf, Active Directory).

Einrichtung einer Kommandositzung zwischen SRCP-Client und -Server nach Protokollversion 0.8. [], ---: optional, 1-8: Handshake-Phase, 9: Kommandoaustausch

Nach Verbindungsaufnahme wird vom Server eine zunächst anonyme Sitzung (Session) gestartet. Diese wird »Handshake« genannt. In ihr kann der Client verschiedene Betriebsparameter einstellen. Derzeit sind zwei unterschiedliche Betriebsmodi definiert: COMMAND und INFO. Weitere Parameter betreffen z.B. die SRCP-Version, die benutzt werden soll. Da die Wahlmöglichkeit für unterschiedliche Protokollversionen erst ab Version 0.8 des SRCP enthalten ist, bieten frühere, aber noch immer benutzte Versionen des SRCP (0.7), diese Möglichkeit nicht.

Mit dem Befehl GO wird die Handshake-Phase beendet und die noch anonyme Session erhält eine Session-ID. Gleichzeitig wird die Verbindung auf den gewählten Betriebsmodus eingestellt. Die Session-ID ist ein numerischer Wert, der die Sitzung identifiziert.

Im Betriebsmodus INFO wird ausschließlich vom Server zum Client kommuniziert. Es werden alle im Protokoll als INFO gekennzeichneten Angaben (Code 100 bis 199) übertragen. Alle Angaben markieren Veränderungen. Der Client beendet die INFO-Session, indem er die Verbindung kappt (es besteht keine Möglichkeit zur Kommandoübermittlung an den Server).

Im Betriebsmodus COMMAND wartet der Server auf Kommandos vom Client. Sobald ein Kommando eintrifft, wird es bearbeitet, eine Antwort generiert und diese an den Client gesendet. Die Antworten sind Bestätigungen dafür, dass das Kommando angenommen wurde, Fehlermeldungen oder Abfrageergebnisse.

Kommandos bestehen aus einem Kommandowort, einer Adressangabe und weiteren Parametern. Kommandoworte bestehen aus Verben, die eine Tätigkeit beschreiben: SET, GET, INIT, TERM usw. Adressangaben sind im allgemeinen dreiteilig: Ein Bus, eine Gerätegruppe und eine Adressangabe (Decoderadresse).

Eine Gerätegruppe markiert Geräte mit gleichen Parametern. Dies können reale Geräte wie Decoder sein (Jeder hat eine Adresse, einen Motor mit unterschiedlichen Fahrstufen und 0 oder mehr Funktionsausgängen) oder nur logische Geräte wie das TIME-Device sein, die nicht unbedingt ein Hardwarependant haben müssen.

Ein Bus kennzeichnet einen Adressraum, über den verschiedene Geräte erreichbar sind. Im einfachsten Fall ist ein Bus eine Verbindung zwischen dem SRCP-Server und dem Computerinterface der Modellbahnanlage.

Gründe für das Design

Parameterlisten versus benamte Parameter

Die Diskussion wurde per Mehrheitsbeschluß entschieden. Eine technische Über- oder Unterlegenheit einer der beiden Varianten konnte nicht festgestellt werden. Allgemein wurde vermutet, dass benamte Parameter aufwendiger in der Umsetzung sind.

Kommandoworte

Die Kommandoworte wurden zugunsten einer größeren Gerätegruppenzahl klein und abstrakt gehalten. Jeden beeinflußbaren Parameter kann man via GET/SET bearbeiten. Es wurde allgemein für einfacher gehalten, neue Gerätegruppen mit den definierten Kommandos zu kombinieren als für neue Geräte auch neue Kommandos einzuführen.

Common Railroad Configuration Files (CRCF)

Ein Entwurf für ein Dateinformat, das eine zentrale Serverkonfiguration beschreibt, stammt von Edbert van Eimeren und ist zur Diskusssion in der Newsgroup de.rec.modelle.bahn freigegeben. Die weitere Entwicklung der Spezifikation und eine Ideensammlung zu dessen Nutzung unter SRCP findet im Abschnitt SRCP-Erweiterungen statt.

• Entwurf CRCF 0.2.0 / CRCF Beispiel

• Historie:
  • Entwurf CRCF 0.1.0