SRCP-Erweiterungen: Unterschied zwischen den Versionen

aus DerMoba, der Wissensdatenbank für Modellbahner
Wechseln zu: Navigation, Suche
K (Abkürzung erläutert)
(Zeroconf-Thematik allgemeiner formuliert)
Zeile 25: Zeile 25:
  
 
==SRCP-Server-Suchdienst==
 
==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag für diese Problematik „zeroconf“ bzw. „Bonjour“ einzusetzen.
+
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 Implementierungen, die beide als OpenSource freigegeben sind:
  
Damit ist es möglich, dass einzelne Clients über Versenden eines ServiceDiscovery-Multicasts in der Lage sind, nach SRCP-Servern zu suchen. Weiterhin wird leicht ermöglicht, dass SRCP-Server ihren Dienst auch auf anderen Ports anbieten können. Auch mehrere SRCP-Server können damit abgedeckt werden. Bonjour-Implementierungen sind auf verschiedenen Betriebssystemen verfügbar. Unter
+
* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
http://www.zeroconf.org/ gibt es mehr Informationen dazu.
+
* [http://avahi.org/ Avahi], als praktisch schon etablierter Standard für Linux.
  
Einen Hinweis zu dieser Art der Implementierung für Service-Discovery in die SRCP-Spezifikation aufzunehmen, wurde nicht begrüßt. SRCP und Bonjour sollen nebeneinander existieren. Nun ist es Sache der Serverentwickler Bonjour mit einzubauen, damit Clients davon profitieren können.
+
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 anderen Wert zu wählen, als in der SRCP-Spezifikation derzeitig festgelegt ist. 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.
 +
 +
(TODO: Beispiel für eine Zeroconf-Serverkonfiguration)
  
 
==CRCF-Erweiterungen==
 
==CRCF-Erweiterungen==

Version vom 16. Januar 2007, 08:35 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 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 anderen Wert zu wählen, als in der SRCP-Spezifikation derzeitig festgelegt ist. 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.

(TODO: Beispiel für eine Zeroconf-Serverkonfiguration)

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.

Meine Anforderungen an CRCF für einen als SRCP-Client operierenden Handregler:

  • Umständlich, in jedem Regler Informationen über Loks und Zubehör einzugeben
  • Anzeige von Klartextnamen anstatt von Adressen
  • Im Bezug auf den Server-Suchdienst könnte CRCF auch die Hostnamen (IP-Adressen) der SRCP-Server verwalten

Weitere Anforderungen aus der Diskussion:

  • Verwaltung statischer Informationen
  • Verwaltung dynamischer Informationen
  • CRCF in ausdruckbarer Form
  • Gliederung der CRCF
  • SRCP-Server sollten Zugriff auf die CRCF erhalten
  • Kommunikation zwischen Clients

Aus diesen Anforderungen ergeben sich wichtige 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)


Mein Vorschlag (auch wenn er etwas mehr Implementierungsaufwand erfordert):

  • Es wird ein CRCF-Server eingerichtet, der einen Auskunftsservice zur Verfügung stellt
  • Dieser kann Bestandteil eines SRCP-Clients oder -Servers sein, greift aber nicht in das SRCP-Protokoll ein
  • Er stellt statische Daten der Modellbahn als XML-Baum dar
  • Alle Netzteilnehmer können über ein Kommunikationsprotokoll die Daten beim CRCF-Server abrufen
  • Diese Kommunikationsprotokoll sollte einfach zu implementieren sein (Auf Grundlage von UDP beispielsweise)

Für die Verwaltung von dynamischen Werten müßte man noch eine Erweiterung vorsehen. Diese Erweiterung könnte so aussehen:

  • Alle Netzteilnehmer können Daten an CRCF übermitteln
  • Die CRCF sorgt dafür, dass die Daten konsistent sind