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


Ultra High Definition: Scharf allein ist nicht genug
Ultra High Definition
Scharf allein ist nicht genug
  1. Ifa Vodafone Deutschland und Cisco bringen 4K-Set-Top-Box
  2. Alpentab Wienerwald Das Holztablet mit Bay Trail oder als Nobelversion
  3. Dell UltraSharp 27 Ultra HD 5K 27-Zoll-Monitor mit 5.120 x 2.880 Pixeln

Neues Moto X im Hands On: Motorolas echtes Topsmartphone
Neues Moto X im Hands On
Motorolas echtes Topsmartphone
  1. Neues Moto G im Hands On Mach's noch einmal, Motorola
  2. Skip 2 Motorolas Schlüsselanhänger für Vergessliche entfleucht
  3. Android Motorola arbeitet an einem 7-Zoll-Tablet

Intel Core i7-5960X im Test: Die PC-Revolution beginnt mit Octacore und DDR4
Intel Core i7-5960X im Test
Die PC-Revolution beginnt mit Octacore und DDR4
  1. Rory Read AMDs neue x86-Architektur Zen kommt 2015
  2. Intels Desktop-Chefin im Interview "Wir hatten unsere loyalsten Kunden frustriert"
  3. Intel Core i7-5960X X99-Mainboards angebrannt

  1. Facebook, Google, Twitter: Branchenweite Interessengruppe zum Open-Source-Einsatz
    Facebook, Google, Twitter
    Branchenweite Interessengruppe zum Open-Source-Einsatz

    Facebook, Github, Dropbox, Google, Twitter und andere haben mit TODO eine Interessensgruppe gebildet, in der die Unternehmen sich über den Einsatz von Open-Source-Software beraten und gegenseitig helfen wollen.

  2. Typ 007: Leica Mittelformatkamera S filmt in 4K
    Typ 007
    Leica Mittelformatkamera S filmt in 4K

    Photokina 2014 Leicas neue Mittelformatkamera S Typ 007 ist mit einem neuen Mittelformatsensor (39 Megapixel) ausgerüstet, der erstmals auch in 4K filmen kann. GPS und WLAN gehören ebenfalls zu den Funktionen der Kamera.

  3. Cloud-Computing: Mathematica Online für den Browser
    Cloud-Computing
    Mathematica Online für den Browser

    Dank der hauseigenen Cloud kommt Mathematica von Wolfram Research nun auch in den Browser. Die Web-Version soll die gleichen Funktionen bieten wie auf dem Desktop und die Kooperation vereinfachen.


  1. 17:00

  2. 16:07

  3. 15:25

  4. 15:01

  5. 14:26

  6. 14:05

  7. 13:58

  8. 13:34