Deprecated: Function set_magic_quotes_runtime() is deprecated in /var/www/morb/textpattern/lib/txplib_db.php on line 14

Warning: Cannot modify header information - headers already sent by (output started at /var/www/morb/textpattern/lib/txplib_db.php:14) in /var/www/morb/textpattern/lib/txplib_misc.php on line 1548
 <txp:posted/> ->  Warning: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1067
 <txp:posted/> ->  Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1068
 <txp:posted/> ->  Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1,0/no DST' instead  on line 1104

Warning: Cannot modify header information - headers already sent by (output started at /var/www/morb/textpattern/lib/txplib_db.php:14) in /var/www/morb/textpattern/publish.php on line 467
MORB: Noch mehr Entwürfe

Noch mehr Entwürfe · Mär 3, 06:35 pm

Das folgende ist im Wesentlichen eine Zusammenfassung/Umstrukturierung/Ergänzung/Weiterentwicklung von J.Schmidts Artikel Morb Spezifizierung Entwurf I

Worüber wir uns einig sind(?)

  1. jeder kann per MORB an einem vernetzten Laptopensemble teilnehmen und seine Teilnahme auch wieder beenden
  2. jeder Teilnehmer kann Daten zur Verfügung stellen(Server) und Daten von anderen verwenden (client)

Daraus folgt m.E. serverseitig:

  1. jeder muss beim Eintritt in ein Ensemble abfragen können, wer welche Daten zur Verfügung stellt (Aus Serversicht: Jeder Server muss bei Eintritt eines neuen Teilnehmers diesem seine Dienste bekanntmachen)
  2. jeder muss beim Eintritt in ein Ensemble den anderen mitteilen, welche Daten er zur Verfügung zu stellen gedenkt.
  3. Sollten sich individuelle Konfigurationsänderungen ergeben, die dazu führen, dass Daten nicht mehr zur Verfügung stehen oder neue Daten erzeugt werden, muss dies auch allen Beteiligten mitgeteilt werden.

Und clientseitig:

  1. jeder kann die Daten eines Servers abonnieren. Ihm werden bei der Entstehung neuer Daten diese dann mitgeteilt.

Vorschlag für eine Implementation

Vorüberlegungen

Ein (nicht M)ORB kann auf klassische Remote Procedure Calls abgebildet werden. Der Client fragt den Server nach den Daten, der Server liefert, damit ist die Transaktion beendet. Aus Sicht der Anwendung wurde lediglich eine lokale Prozedur aufgerufen, der dazwischen liegende Netzwerklayer ist transparent.

Dieser Ansatz führt bei unserem Modell nicht weiter, denn der Client will die Daten, wenn sie anfallen, sobald als möglich haben, ohne überflüssigerweise Abfragen starten zu müssen, die nichts bringen, wenn sich die Daten nicht verändert haben. Wir müssen also von einem Abfrage- oder Pull-Modell zu einem Abonnement- oder Push- modell.

In diesem ist das Entstehen eines neuen Datensatzes beim Server für den Client ein Event, auf das er eine Reaktion definieren kann, ähnlich dem lokalen Eintreffen eines MIDI- oder OSC Ereignisses.

Die zunächst geplanten Plattformen (Max/MSP und ChucK) bieten von sich aus ein Datenflussmodell, dass ein solches Eventhandling “von Hause aus” bietet oder sogar paradigmatisch darauf basiert (Max).

Bleibt, pragmatische Lösungen für den unteren (Netzwerk-)layer zu finden.
Auch hier hilft das RPC Modell nicht weiter, denn jeder RPC Call stellt eine 1:1-Verbindung zwischen einem Server und einem client dar.

Dies abgebildet auf ein 1:N Abonnement Modell bedeutet, dass der Server für jeden seiner Dienste eine Liste von Abonnenten unterhält, und jeden dieser Abonnenten beschickt, sobald neue Daten entstehen. In einem Netzwerk, wo mittels geeigneter Hardware (Switches) bei einer 1:1 Verbindung die volle Bandbreite zur Verfügung steht, wäre dieser Ansatz wahrscheinlich der Netz-ökonomischste. Da der Funkkanal eines WLAN Netzes jedoch ein geteiltes Medium ist (siehe hier ), und wir ja kabelarm arbeiten wollen, entfällt dieser Vorteil, und wir können uns etwas anderes überlegen. Ausserdem müsste der Server möglicherweise jede Datenveränderung mehrmals (an jeden client einmal) versenden, was die Serverlast erhöht.

Broadcasting, bei dem alle alles mithören müssen, führt auf der anderen Seite zu einer überflüssigen Last auf dem client.

Lösungsvorschlag

Ein möglicher Kompromiss wäre eventuell IP-Multicasting (siehe hier )

Da die Multicast Adressen netzwerkübergreifend gleich sind, wäre insbesondere der Beitritt zu einem MORB Ensemble ohne weitere Netz-Infrastruktur (Dhcp-server etc.) möglich.

Das ganze könnte so aussehen:

  1. es gibt einen Multicast Kanal, für die Verwaltung des Gesamtensembles. den müssen alle hören. Quasi MORB Broadcast
  2. jeder Teilnehmer erhält einen Multicast Kanal auf dem er seine Daten senden kann.
  3. Jeder Teilnehmer erfragt auf dem Broadcast Kanal die anderen Teilnehmer, deren Multicast Adresse und die von ihnen angebotenen Services
  4. er reserviert eine der noch freien Multicastadressen für sich und teilt den anderen über den Broadcastkanal seine Dienste und seine Multicast Adresse mit.
  5. Ein Client, der einen Dienst abonnieren möchte, teilt dies dem Server mit und tritt der Multicastgruppe bei. Er erhält dann alle Daten von diesem Server und muss die, die ihn interessieren ausfiltern. Dies kann per OSC-Routing passieren, wie von J.Schmidt vorgeschlagen.
  6. Ein Server, der einen Abonnementwunsch erhält, zählt mit, wieviel cients diesen Dienst abonnieren. Solange der Zähler größer 0 ist, sendet der Server bei neuen Daten diese, eingebettet in eine entsprechende OSC Nachricht über seinen Multicast Kanal. Alle clients hören dort mit, der Server braucht nur einmal zu senden.
  7. verläßt ein Client das Ensemble oder konfiguriert sich um, muss er sich von allen Diensten abmelden.
  8. Nicht ordnungsgemäßes Abmelden sollte durch Heartbeating oder fehlgeschlagenes (speziellen MORB-) Pinging erkannt werden und die Abonnements entsprechend gecancelled werden.

…more to come… please comment

— Thomas Neuhaus

---

Kommentare

Kommentarfunktion für diesen Artikel geschlossen.