1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › IPC: Linux-Kernel soll D-Bus…

Hmm, warum nicht einfach TCP/IP?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Hmm, warum nicht einfach TCP/IP?

    Autor: Casandro 11.02.13 - 13:13

    Das ist schon im Kernel, man kann damit Daten zwischen Prozessen übertragen. Es ist hoch-performant, und es funktioniert sogar im Netzwerk.
    Sprich einfach ein Protokoll das direkt auf TCP/IP aufsetzt, und schon können Prozesse untereinander kommunizieren.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: BRDiger 11.02.13 - 13:25

    Das dachte ich mir auch.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Warum nicht mit Hammer und Meißel ein Schiff bauen?

    Autor: ChilliConCarne 11.02.13 - 13:36

    Bitte diesen Gedanken mit TCP/IP wieder aus dem Kopf schlagen, bzw. alles mit TCP/IP erschlagen zu wollen. Verschiedene 'Protokollklassen' haben ihren Daseinsgrund.
    Man lese nur mal als Ansatz: http://dbus.freedesktop.org/doc/dbus-faq.html#other-ipc

    Ein gewisser Draxinger der die selbe Schnappsidee hatte - übrigens eine unter vielen - kam bei einem Vortrag auch prompt die Reaktion von Poettering zu spüren (ab Minute 40):
    http://www.youtube.com/watch?v=ZTdUmlGxVo0

    Und nein, das war nicht arrogant, sondern bei so viel wirrem Zeug auf einer, vor allem öffentlichen, Veranstaltung notwendig.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Warum nicht mit Hammer und Meißel ein Schiff bauen?

    Autor: Casandro 11.02.13 - 14:26

    OK, ich hab damals den Vortrag gesehen. Und ich fand eher den Einwurf von Poettering reine Trollerei.
    Irgendwie hab ich seit damals dbus als Schnappsidee im Kopf die man eigentlich unter "Unix" nicht haben will, weil sie nicht unixoid ist. Für mich ist das in der selben Kategorie mit Pulseaudio und binären Logdateien.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: Astorek 11.02.13 - 14:32

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > Es ist hoch-performant, und es funktioniert sogar im Netzwerk.
    > Sprich einfach ein Protokoll das direkt auf TCP/IP aufsetzt, und schon
    > können Prozesse untereinander kommunizieren.

    Das ist, Sorry, ein schlechter Scherz und definitiv einer der schlechtesten Lösungen in dem Bereich. TCP/IP hat viel zuviel Overhead, um eventuelle Verbindungsabbrüche zu kompensieren (alleine der Handshake) oder mit unterschiedlicher Segmentbreite umzugehen. Aber den ganzen Rotz braucht man zwischen einer Anwender- und Systemschnittstelle nicht und sorgt nur für vergeudete (wertvolle) Zeit. Sobald der Rechner dann unter Last läuft, kriegst du mit TCP/IP zwischen den Prozessen eine weit schlechtere Performance als mit der aktuellen Lösung. "Weit schlechtere" ist eigentlich noch untertrieben, "katastrophal langsamer" würde es eher treffen...

    Aus Anwendersicht braucht man sich eigentlich alleine nur Software ansehen, die selbst unter localhost über TCP/IP kommunizieren, etwa bei VMware Server für die Bildschirmausgabe: Unter "normalen" Bedingungen geht das in Ordnung, aber eine performante, schnelle Ausgabe sieht anders aus...

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Warum nicht mit Hammer und Meißel ein Schiff bauen?

    Autor: Astorek 11.02.13 - 14:42

    Ich habe den Vortrag inkl. Poetterings Einwurf nicht gesehen, möchte aber zu Pulseaudio was sagen:

    Pulseaudio mag auf der einen Seite nicht unixoid sein, aber es hebt viele Beschränkungen der vorhergehenden Soundsysteme aus, die seit Jahren (oder Jahrzehnten?) nicht angegangen wurden und speziell Desktopsystemen einen Mehrwert beschert. Ich für meinen Teil finde es ganz praktisch, dass ich endlich mal die Lautstärke und die Ein-/Ausgabegeräte jeder einzelnen Anwendung einzeln steuern kann, ohne dass die Anwendersoftware selbst etwas davon mitbekommen muss. (Gibts eigentlich ein äquvalent zu "pavucontrol" auch für alsa?)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: Casandro 11.02.13 - 14:58

    Astorek schrieb:
    --------------------------------------------------------------------------------
    > Das ist, Sorry, ein schlechter Scherz und definitiv einer der schlechtesten
    > Lösungen in dem Bereich. TCP/IP hat viel zuviel Overhead, um eventuelle
    > Verbindungsabbrüche zu kompensieren...

    Das ist genau der Punkt, der mich immer von d-bus abhält. Immer dann wenn man eine Frage stellt, kommt einem ein Wust an Polemik und Unwahrheiten entgegen. Niemand scheint _sachlich_ für d-bus zu argumentieren.
    Wenn Dir der Overhead von TCP zu viel ist, nimm halt UDP her, das ist lokal zuverlässig und kann sogar Multicast.


    Pulseaudio funktioniert immerhin inzwischen weitgehend. Das Äquivalent zu pavucontrol in alsa ist alsamixer und alsactl, wobei Alsa halt einfach halbwegs funktioniert hat. Und selbst OSS hatte schon die Unterstützung für mehrere Quellen gleichzeitig drin.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: Astorek 11.02.13 - 15:18

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > Das ist genau der Punkt, der mich immer von d-bus abhält. Immer dann wenn
    > man eine Frage stellt, kommt einem ein Wust an Polemik und Unwahrheiten
    > entgegen. Niemand scheint _sachlich_ für d-bus zu argumentieren.
    > Wenn Dir der Overhead von TCP zu viel ist, nimm halt UDP her, das ist lokal
    > zuverlässig und kann sogar Multicast.
    Ganz ehrlich: Hab ich mir während des Tippens auch gedacht. Aber dann sag das doch auch; woher soll ich riechen, dass du mit TCP/IP auch UDP gemeint hast? ;)


    > Pulseaudio funktioniert immerhin inzwischen weitgehend.
    Pulseaudio hatte v.a. zu Anfang recht kritische Probleme, die allerdings - soweit ich das beurteilen kann - aus der Welt geschafft wurden.

    Mich würde ehrlichgesagt interessieren, welche Probleme bei dir Pulseaudio noch verursacht oder wo noch irgendwo etwas falsch läuft.

    > Das Äquivalent zu pavucontrol in alsa ist alsamixer und alsactl, wobei Alsa halt einfach halbwegs funktioniert hat.
    Sorry, aber sieh dir sowohl den alsamixer als auch alsactl nochmal an - oder umgekehrt, sieh dir erstmal pavucontrol an: Wo kann ich mit den beiden Kommandos bitteschön die Lautstärke, die Ein-/Ausgabegeräte und evtl. Filter für jede einzelne Anwendung, die über Pulseaudio kommuniziert, einstellen? (EDIT: Mit Hervorhebung von "jede einzelne Anwendung") Das wär mir neu, wenn alsamixer das plötzlich auch könnte...

    Abermals bitte ich dich, zu sagen, welche Probleme du mit pavucontrol hast oder hattest. Ich verwende Archlinux auf ingesamt 3 PCs inkl. Pulseaudio und mache öfters mal Aufnahmen mit unterschiedlichen "Eingangsgeräten", bei mir luppt es einfach...



    1 mal bearbeitet, zuletzt am 11.02.13 15:21 durch Astorek.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: Casandro 11.02.13 - 15:26

    Naja, mal von der fehlenden Unterstützung von OSS abgesehen. (da kann man sich drüber streiten ob man die noch braucht)

    Ich hab bei mir im Wohnzimmer einen AV-Receiver. So ein 7.1 Ding. Wenn ich Stereovideos sehe, so will ich, dass der Receiver ein Stereosignal kriegt, da er dann das selber auf 5.1 umrechnen kann. (Sprache auf Center, etc)
    Will ich 5.1 Video sehen, so soll da auch ein 5.1 Ton ankommen.

    Im Moment muss ich dafür immer die Tastatur hernehmen mit dem Trackpad zu dem Fenster hinklicken das Programm starten und aus Paaren gleich beschrifteter Ausgabegeräte das richtige auswählen. Immerhin steht "Stereo" und "5.1" im Namen. Alsa macht das einfach automatisch richtig. :)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: taschenorakel 11.02.13 - 22:51

    Casandro schrieb:

    > Das ist genau der Punkt, der mich immer von d-bus abhält. Immer dann wenn
    > man eine Frage stellt, kommt einem ein Wust an Polemik und Unwahrheiten
    > entgegen. Niemand scheint _sachlich_ für d-bus zu argumentieren.

    Versuche ich's mal: D-Bus ist eine bewährte IPC-Implementierung mit ausdruckstarker Semantik, welche auf jedem (halbwegs standardkonformen) Linux-System vorinstalliert ist. D-Bus wird durch jedes größere Linux-Framework (mal mehr, mal weniger gut) von Hause aus unterstützt. Benötigt man also für eine Linux-spezifische Software einen robusten und ausgereiften IPC-Mechanismus, ist es naheliegend, zu D-Bus zu greifen. Schlicht weil er genauso wie die C-Standard-Library, die GNU command line tools, ... einfach schon vorhanden ist, von vielen Leuten verstanden wird und in den meisten Fällen auch noch mehr als hervorragend funktioniert.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  11. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: Casandro 12.02.13 - 07:31

    OK, was war bislang wirklich das Sachlichste, was ich gehört habe, was aber nicht viel bedeutet. Im Prinzip ist Dein Argument, wenn ich Dich richtig verstanden habe, dass es schon da ist, und von vielen Leuten verwendet wird, und deshalb gut ist. Hmm...

    Als Beispiel für andere Dinge bei denen es so ähnlich ist, listest Du die "GNU command line tools" auf. Bei denen gibt es aber eine grundlegende Philosophie, die dahinter steckt. Sie ist im Buch "The Art of Unix Programming" beschrieben.
    Was ich mich jetzt frage, gibt es solch ein Buch auch für d-bus, quasi ein Werk das einem in die Gedankenwelt hinter d-bus einführt?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  12. Re: Warum nicht mit Hammer und Meißel ein Schiff bauen?

    Autor: ChilliConCarne 12.02.13 - 10:14

    Der Vortrag selber, war aufgrund seines großen Nonsens Anteils eine einzige Trollerei. Tut mir leid, aber da sind dann irgendwann solche Einwände angebracht. Vor allem wenn man Entwickler der Technologien ist und das hauptberuflich ausführt. Dass Leute angebrachte Kritik und Trollerei immer so schnell vermischen müssen.

    Und WER sagt bitte, dass man D-Bus nicht unter Unix haben will? D-Bus nutzt ganz einfach Unix Sockets und TCP/IP.
    http://dbus.freedesktop.org/doc/dbus-daemon.1.html

    Nur während du mit TCP/IP jeden Misst selbst spezifizieren musst (ob du es merkst oder nicht, implizit legst du einen weiteren Layer drüber) und du dich auch noch darauf verlassen musst, dass die Gegenstelle bei der IPC dein "Protokoll" kennt und KORREKT interpretiert, hast du bei D-Bus die Dinge die speziell für diesen ANWENDUNGSFALL des NACHRICHTENAUSTAUSCHS bereits mit drin. Und du hast zumindest eine gewisse Garantie, dass die Gegenstelle bei der IPC, sofern die D-Bus nutzt, das alles auch versteht! Lies einfach nochmal den ersten Link meines letzten Beitrags.

    Alles mit TCP/IP machen zu wollen, ist als ob man alles mit Assembler umsetzen möchte und komplett auf höhere Konzepte verzichtet. Oder du kannst gleich auf http, ftp, pop3, imap usw. verzichten und die Pakete von Hand versenden.

    D-Bus ist, wie es Poettering im Vortrag schon nannte, ein "smarter socket". Punkt.

    Hier ist ebenfalls eine treffende Antwort:
    https://mail.gnome.org/archives/gnome-accessibility-list/2010-July/msg00046.html

    Benutzer wird von Ihnen ignoriert. Anzeigen

  13. Re: Hmm, warum nicht einfach TCP/IP?

    Autor: taschenorakel 12.02.13 - 13:11

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > OK, was war bislang wirklich das Sachlichste, was ich gehört habe, was aber
    > nicht viel bedeutet. Im Prinzip ist Dein Argument, wenn ich Dich richtig
    > verstanden habe, dass es schon da ist, und von vielen Leuten verwendet
    > wird, und deshalb gut ist. Hmm...

    "und deshalb gut ist" - Nein! Das wäre ja haarsträubender Blödsinn!

    Das Argument ist: "Es ist schon da und erledigt die zugewiesene Aufgabe recht gut".

    > Was ich mich jetzt frage, gibt es solch ein Buch auch für d-bus, quasi ein
    > Werk das einem in die Gedankenwelt hinter d-bus einführt?

    Erster Anlaufpunkt wäre freedesktop.org: http://www.freedesktop.org/wiki/Software/dbus
    Mag alles etwas dünn erscheinen, liegt aber daran, dass wirklich nichts Besonderes dran ist an D-Bus - außer dass sich ein paar Leute auf ein einfach zu handhabendes IPC-Nachrichten-Format geeinigt haben. Der komplizierteste Teil ist erstaunlicherweise die Session-Authentifizierung: http://dbus.freedesktop.org/doc/dbus-specification.html - Im Gegensatz zu all dem FUD im Umlauf (und der wirklich arg uneffizienten Implementierung in Qt), ist das wirklich alles recht minimal und "lightweight".

    Benutzer wird von Ihnen ignoriert. Anzeigen

  14. Re: Warum nicht mit Hammer und Meißel ein Schiff bauen?

    Autor: datenwolf 13.02.13 - 00:19

    @ChilliConCarne

    Du hast meinen Talk entweder nicht genau verfolgt oder käust hier nur Hörensagen wieder. Ich persönlich bin einer der erbittertsten Gegner des ganzen D-Bus-Konzepts und habe den Irrsinn, D-Bus in den Kernel einbauen zu wollen (die Sau wird nicht zum ersten mal durch's Dorf getrieben) scharf kritisiert.

    An den Folien meines Talks kann man leicht ersehen, dass ich absolut kein Freund von D-Bus bin. Mein Gegenvorschlag, schon damals war, einfach IPv6 Node-Local-Multicast zu verwenden. Pötterings Einwand "it's a Network Transport", das ist mir heute klar, hätte ich einfach mit "Yes it is, that's the great thing about it" beantworten sollen, anstatt rumzustammeln. Auf die Frage, wie das gehen soll, verweise ich auf RFC-3259.

    IPv6-Node-Local-Multicast ist genau für sowas vorgesehen. Node-Local-Multicast bedeutet nämlich, dass die Pakete das Gerät gar nicht erst verlassen und auch nicht routed werden. Es handelt sich dabei um genau die Art von IPC, fix und fertig im Kernel implementiert und man müsste dazu nur die IPv6-Fähigkeit des Loopback-Geräts berichtigen.

    Ich verbitte mir, dass mir meine Aussagen im Mund ins Gegenteil verkehrt werden.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Moore's Law: Totgesagte schrumpfen länger
Moore's Law
Totgesagte schrumpfen länger

OS X Yosemite im Test: Continuity macht den Mac zum iPhone-Helfer
OS X Yosemite im Test
Continuity macht den Mac zum iPhone-Helfer
  1. OS X 10.10 Yosemite ist da
  2. Betriebssystem Apple bringt dritte öffentliche Beta von OS X 10.10
  3. Apple OS X Yosemite - die zweite öffentliche Beta ist da

Samsung Galaxy Note 4 im Test: Ausdauerndes Riesen-Smartphone mit Top-Hardware
Samsung Galaxy Note 4 im Test
Ausdauerndes Riesen-Smartphone mit Top-Hardware
  1. Galaxy Note 4 4,5 Millionen verkaufte Geräte in einem Monat
  2. Samsung Galaxy Note 4 wird teurer und kommt früher
  3. Gapgate Spalt im Samsung Galaxy Note 4 ist gewollt

  1. Streaming-Dienst: Netflix-App für Amazons Fire TV ist da
    Streaming-Dienst
    Netflix-App für Amazons Fire TV ist da

    Amazon hat die deutsche Netflix-App für die Streaming-Box Fire TV veröffentlicht. Vor der Installation der App muss eine neue Firmware auf das Fire TV installiert werden. Wer bereits die US-Version der Netflix-App genutzt hat, muss sich erneut anmelden.

  2. Pilot tot: Spaceship Two stürzt in der Mojave-Wüste ab
    Pilot tot
    Spaceship Two stürzt in der Mojave-Wüste ab

    Spaceship Two, das Raketenflugzeug des Raumfahrtunternehmens Virgin Galactic, ist in der Mojave-Wüste abgestürzt. Dabei kam wohl der Co-Pilot ums Leben, der Pilot soll schwer verletzt sein. Wie es zu dem Unglück kam, ist zur Stunde nicht bekannt. Das Trägerflugzeug WhiteKnightTwo landete unversehrt.

  3. Bewegungsprofile: Dobrindt wegen "Verkehrs-Vorratsdatenspeicherung" kritisiert
    Bewegungsprofile
    Dobrindt wegen "Verkehrs-Vorratsdatenspeicherung" kritisiert

    Das Versprechen von Verkehrsminister Dobrindt, dass das Mautsystem nicht zur Bildung eines massenhaften Bewegungsprofils der Bevölkerung genutzt wird, nimmt kaum einer ernst. Dobrindt versichert: "Kein Bürger muss Sorge haben, dass jetzt irgendwo Profile gespeichert werden könnten."


  1. 23:29

  2. 23:23

  3. 17:58

  4. 17:56

  5. 15:04

  6. 14:57

  7. 14:02

  8. 13:38