Änderungen

Zur Navigation springen Zur Suche springen
277 Bytes hinzugefügt ,  21:02, 11. Sep. 2013
Zeile 129: Zeile 129:     
P2P-Anwendungen müssen regelmäßig mit dem Problem zurechtkommen, dass eine oder beide "Peers" über ein NAT mit dem Internet verbunden sind und daher grundsätzlich keine direkte Verbindung zwischen beiden zustande kommt. Die Lösung funktioniert über ein drittes System, das sich unmittelbar im Netz befindet, also nicht hinter einer Firewall sitzt. Die Peers verbinden sich zunächst mit diesem und dieser stellt dann eine direkte Verbindung zwischen den beiden Peers her, indem er jeweils seine Endpunkt-Metadaten dem jeweils anderen Peer gibt (jeder Peer setzt sich für den anderen Peer an die Stelle des Drittsystems).
 
P2P-Anwendungen müssen regelmäßig mit dem Problem zurechtkommen, dass eine oder beide "Peers" über ein NAT mit dem Internet verbunden sind und daher grundsätzlich keine direkte Verbindung zwischen beiden zustande kommt. Die Lösung funktioniert über ein drittes System, das sich unmittelbar im Netz befindet, also nicht hinter einer Firewall sitzt. Die Peers verbinden sich zunächst mit diesem und dieser stellt dann eine direkte Verbindung zwischen den beiden Peers her, indem er jeweils seine Endpunkt-Metadaten dem jeweils anderen Peer gibt (jeder Peer setzt sich für den anderen Peer an die Stelle des Drittsystems).
 +
 +
Die Idee ist die, dass Peer P1 sich sich über den Router/NAT R1 mit dem Server S verbindet und P2 dasselbe über R2 tut.
 +
    
Siehe
 
Siehe
* [http://www.alexonlinux.com/reverse-ssh-tunnel-or-connecting-to-computer-behind-nat-router Reverse SSH tunnel]
+
* Die [http://www.alexonlinux.com/reverse-ssh-tunnel-or-connecting-to-computer-behind-nat-router Reverse SSH tunnel]-Methode führt zwar zu einem sicheren Weg, den die Daten zwischen den beiden Peers nehmen. Allerdings läuft der gesamte Datenstrom über den Peer.
    
Siehe auch
 
Siehe auch

Navigationsmenü