Scuzzle: Browser: Peer-To-Peer

Hallo,

nebst der üblichen Client-Server-Kommunikation wären in meiner Webanwendung eine große Anzahl an Plaintextpakete, die zwischen zwei Browsern ausgetauscht werden müssten. Da der Server diese Daten nicht braucht, wäre das übliche Pollen ziemlicher Overhead.
Viel eleganter wäre eine Peer-To-Peer Kommunikation zwischen den beiden Browsern.
Ich weiß, mit Boardmitteln ist das nicht machbar, aber gibt es keine Möglichkeit mittels Flash, Silverlight (Neues Microsoft-Pendant zu Flash) oder einem Crossbrowser-PlugIn, einfache Textdaten zwischen zwei Browsern auszutauschen?

Über eine Antwort würde ich mich freuen.

bye
Scuzzle

  1. Hallo!

    Ich weiß, mit Boardmitteln ist das nicht machbar, aber gibt es keine Möglichkeit mittels Flash, Silverlight (Neues Microsoft-Pendant zu Flash) oder einem Crossbrowser-PlugIn, einfache Textdaten zwischen zwei Browsern auszutauschen?

    Zertifizierte Java Applets wären eine Möglichkeit. Der Aufwand aber auch ziemlich hoch und es ist noch lange nicht gesagt, dass alle Benutzer Java Applets zulassen.

    Mit den von dir erwähnten Techniken hab ich keine Erfahrung.

    mfg
      frafu

  2. Hallo,

    Ich weiß, mit Boardmitteln ist das nicht machbar, aber gibt es keine Möglichkeit mittels Flash, Silverlight (Neues Microsoft-Pendant zu Flash) oder einem Crossbrowser-PlugIn, einfache Textdaten zwischen zwei Browsern auszutauschen?

    So ohne weiteres nicht. Du hast 2 Probleme:

    1. Sicherheitsmechanismen: Im Browser ausgeführte Scripte etc. (auch Flash!) dürfen nur auf den Server, von dem sie auch geladen wurden, zugreifen - wenn man von potentiellen Lücken in den Mechanismen mal absieht. Stell Dir mal vor, ein Flash auf Deinem Rechner könnte Verbindungen zu beliebigen Rechnern aufbauen - dann könnte jemand bösartiges von Deiner IP-Adresse aus Spam versenden, andere Rechner angreifen oder ähnliches - und das im Idealfall, ohne eine wirkliche Spur zu hinterlassen. Sehr schlecht.

    2. NAT. *Sehr* viele Rechner sitzen heutzutage hinter Routern. Das heißt: Wenn Du die öffentlich sichtbare IP des anderen Rechners kontaktieren willst, kontaktierst Du im Endeffekt nur den Router des anderen - nicht den Rechner selbst. Wenn also beide hinter NAT sitzen (und das ist sehr wahrscheinlich heutzutage), hast Du ein großes Problem. Software wie Skype verwendet relativ fortgeschrittene Techniken wie UDP hole punching, um das irgendwie trickreich zu umgehen - und selbst das klappt nicht immer, manchmal werden auch Skype-Telefonate über deren Server abgewickelt.

    Du hättest eine Chance wenn Du Dich in einem Intranet bewegst, wo a) NAT keine Rolle spielt und Du b) dafür sorgen kannst, dass für zumindest Deine Intranet-Seite andere Sicherheitsbedingungen im Browser gelten. Java zum Beispiel kennt signierte Applets, die (wenn man der Signatur vertraut, was im Intranet möglich ist) viel mehr dürfen, als normale Applets - z.B. auch auf lokale Dateien zugreifen o.ä. - und eben auch Verbindungen zu beliebigen IPs aufbauen können. Vielleicht kennt Flash oder Silverlight sowas ähnliches.

    Im Internet dagegen wirst Du Flash-/Silverlight-/Java-basiertes P2P im Prinzip vollkommen vergessen können - zwar kann man signierte Java-Applets auch im Internet verwenden (wenn die Leute das akzeptieren, was zumindest bei einem geschlossenen Nutzerkreis denkbar wäre), dafür hast Du aber weiterhin das NAT-Problem. Und verzeih mir, aber irgendwie traue ich Dir bei Deinem aktuellen Wissensstand nicht zu, NAT-Traversal-Techniken wie UDP Hole Punching o.ä. korrekt zu implementieren.

    Viele Grüße,
    Christian

    1. Vielen Dank für deine kompetente Antwort. Du hast Recht, UDP Hole Punching könnte ich wirklich nicht implementieren, da ich mich als Entwickler nicht auf Netzwerk-I/O spezialisiert habe.
      Aber dass du meinen kompletten Wissensstand kennst, finde ich faszinierend. Dann lege mir doch mein detailiertes Wissensprofil vor.

      1. Hallo,

        Aber dass du meinen kompletten Wissensstand kennst, finde ich faszinierend. Dann lege mir doch mein detailiertes Wissensprofil vor.

        Uh, ich fürchte, Du hast das in den falschen Hals bekommen. Eigentlich bin ich nur von folgendem ausgegangen: Jemand, der UDP Hole Punching implementieren könnte, hätte Deine Frage in der Form, wie Du sie gestellt hast, nicht gestellt. Ist ja auch nicht weiter schlimm, nicht jeder muss sich in jedem Detail auskennen, ich habe zum Beispiel so gut wie keine Ahnung von Flash. ;-)

        War wirklich nicht böse gemeint, ich wollte Dir nur eine Einschätzung geben, wie realistisch es sein dürfte, dass Du das implementiert bekommst.

        Viele Grüße,
        Christian

        1. Okay danke für die Richtigstellung, so kann man damit leben.

  3. Hi Scuzzle,

    Wenn diese anwendung nur einem engen Benutzerkreis zugänglich sein soll,
    könnte dir das Stichwort "Port-Forwarding" behilflich sein. Sichherheitstechnisch müsstest du aber einiges bedenken...

    Viele Grüsse

    gary

    1. Hallo!

      Wenn diese anwendung nur einem engen Benutzerkreis zugänglich sein soll,
      könnte dir das Stichwort "Port-Forwarding" behilflich sein. Sichherheitstechnisch müsstest du aber einiges bedenken...

      Inwiefern könnte hier Port-Forwarding behilflich sein?

      mfg
        frafu

      1. Hi frafu,

        Punkt zwei aus Christians Antwort. Viele Rechner sitzen hinter Routern. Keine Chance da durch zu kommen - ausser die Leute, die zum Projekt gehören schalten einen ihrer Ports frei/durch.

        Ich habe dass erst einmal gemacht und das ist schon lange her. Bei Bearshare beispielsweise musste man seinen Router so freigeben, das man "ziehen" und "gezogen" werden konnte. Das Bonussystem damals belohnte die Offerierer grosser Datenmengen mit mehr "Zuggeschwindigkeit". Und Gnutella ist ja auch peer to peer - soweit ich weis.

        Ansatz wäre, dass das Problem mit der internen IP dann wegfallen würde.

        Allerding schrieb ich ja bereits im anderen Post, dass man sich bei so einer Lösung gedanken um die Sicherheit machen muss...

        Viele Grüsse gary

        1. Moin!

          Punkt zwei aus Christians Antwort. Viele Rechner sitzen hinter Routern. Keine Chance da durch zu kommen - ausser die Leute, die zum Projekt gehören schalten einen ihrer Ports frei/durch.

          Also ist Port-Forwarding Teil des Problems, nicht Teil der Lösung.

          - Sven Rautenberg

          --
          "Love your nation - respect the others."
          1. Hi Sven,

            Hier
            Steht ganz ganz grob was über Port-Forwarding. Man kann, wenn man sich abspricht, das Durchreichen (Interne und Externe IP) von Informationen einstellen. Port im Sinne von Türen. Ich bin kein Profi. Aber wenn es möglich ist, das durch offene Ports Hacker, Diebe und andere unliebsame Zeitgenossen Daten klauen und Vieren einschleussen, dann ist es logischerweise auch möglich "absichtlich" Daten über das Internet von Client zu Client zu schicken. Die Schwierigkeit dabei wird sein, dies über einen Browser zu managen (so war es glaube ich im OP gedacht). Browser sind aber normal dazu gedacht, mit Servern zu kommunizieren. Das bedeutet das du in dem Fall ein Programm brauchst, das deinen PC als Sender und Empfänger arbeitet (so ne Art Servermodus) Das muss wahrscheinlich bei jedem im Benutzerkreis installiert werden. Siehe Bearshare / LimeWire und Co. Ist überall installiert, da es sonst nicht funktioniert.

            Und für eine Problemlose Verbindung durch die Firewall hindurch brauchst du eben PortForwarding. Ob ich das so lösen würde - klares nein, da zu unsicher. Aber ich leide ja sowieso unter Net-Paranoia ;-)

            Viele Grüsse gary