Guten Morgen,
Ich habe vor Ewigkeiten mich über die Technik schlau gemacht und theoretisch kenne ich mich auch aus; ist ja auch nicht allzu komplex.
Ich hab kurzerhand zwei kleine Anwendungen (Übermittler & Peer) geschrieben, um das mal direkt naiv zu testen.

Kurz noch zum Hole-Punching (so wie ich das verstanden habe; bitte korrigieren falls notwendig):
Szenario: Peer A & B befinden sich jeweils hinter einem Router & in verschiedenen Netzen.
Hintergrund: Bei TCP muss ein Portforwarding eingerichtet werden, damit ein Peer (Server) Daten empfangen kann.
Da aber UDP verbindungslos ist, regelt NAT das so, dass sobald von Peer A Pakete an B geschickt werden, ankommende Pakete von B an A weitergeleitet werden;
weil er eben annimmt, dass es Antworten auf die Pakete sind (für solch eine Session gibts auch ein Time-out - deshalb sollte man ein konstantes hole-punching (keep-alive) durchführen).
Technik: Nun verbinden sich beide Peers an den Übermittler, diese reicht dann beide IPs weiter sodass nun beide Peers einander "kennen". Also Peer A kennt die IP (&Port) von Peer B und vice versa.
Nun schicken beide Peers zyklisch Dummy-Pakete zueinander - diese Sorgen dafür, dass NAT eben eingehende Pakete auch weiterleitet (siehe Hintergrund).

NUN zum eigentlichen Problem -.-' Das ganze funktioniert nicht. Die Peers können miteinander nicht kommunizieren.

Ich hab das so eingerichtet, dass ich den "Übermittler" spiele, hab zwei Kollegen die Peer-Anwendung geschickt. Beide konnten sich fehlerfrei zu mir verbinden.
Beide haben dann auch die Daten voneinander übermittelt bekommen. Dabei ist mir übrigens aufgefallen, dass die Ports nicht richtig waren.
Soweit ich mich richtig erinnere, haben die sich sogar ständig geändert -> Potenzielle Problemquelle #1: Port Randomization?

Nach kurzem recherchieren hab ich rausgefunden, dass es ~3 Arten von NAT gibt und das Verfahren beim "Symmetric NAT" (Potenzielle Problemquelle #2) nicht funktioniert.
Ich darf aber doch davon ausgehen, dass es sich bei den Kollegen nicht um diese Art von NAT handelt, da ja auch Skype und diverse andere P2P Anwendungen bei denen funkltionieren.
(Oder verwenden diese Anwendungen andere Techniken?)

Sofern das Problem #1 tatsächlich ist - was mach ich da? (STUN? Steht #1 mit #2 iwie in Beziehung?)

Achja, was beim Peer wirklich abgeht (vlt tuts ja was zur Sache):

markieren

Code:

- in 10 Sek. Abständen ein "Hallo" an "Übermittler" schicken. Der Übermittler aktualisiert seine Peerliste (mit Zeitstempel, sodass Peers die 30 Sek. lang keine Murks von sich gegeben haben, gelöscht werden)
- recvfrom() ausführen
  falls daten vom "Übermittler" gekommen sind
     es handelt sich um die PeerListe - parsen
  sonst (zu diesem Abschnitt kommts nie! =()
     entweder Nachricht von einem Peer empfangen oder hole-punching (nachricht anzeigen, hole punching ignorieren)
- an alle Peers (Peerliste) hole-punching Pakete verschicken

(Das ganze läuft übrigens ~100 x die Sekunde)

Hat einer ne Idee woran es liegen könnte?
Würde mich über jede Kleinigkeit freuen.
Ich hoffe sehr, dass zumindest einer positive Erfahrung damit hat.

Zitat von Aphton:

Da aber UDP verbindungslos ist, regelt NAT das so, dass sobald von Peer A Pakete an B geschickt werden, ankommende Pakete von B an A weitergeleitet werden;

Das wäre mir neu
Zumindest keiner meiner Router konnte das. Dafür muss man meist per Hand eine Regel festlegen.

Viele Anwendungen benutzten UPnP, um das NAT einzurichten. Skype ist noch etwas komplizierter ... schwarze Magie

.. hier ist "hole punching" recht anschaulich beschrieben.

Grüße
Klaus

@Klaus das kenne ich schon.. Genau das habe ich ja auch beschrieben..
Trotzdem danke

Zitat von BUG:

Skype ist noch etwas komplizierter ... schwarze Magie

Zitat von Klaus01:

.. hier ist "hole punching" recht anschaulich beschrieben.

Ah, das meinte ich. Hatte bloß noch die falsche Erinnerung, dass das ganze über eine vorgegaukelte TCP-Verbindung funktioniert. Also doch keine schwarze Magie

Zitat von Aphton:

Ich darf aber doch davon ausgehen, dass es sich bei den Kollegen nicht um diese Art von NAT handelt, da ja auch Skype und diverse andere P2P Anwendungen bei denen funkltionieren.
(Oder verwenden diese Anwendungen andere Techniken?)

Wie gesagt, im Normalfall benutzen P2P-Anwendungen UPnP. Skype macht das auch.

Habs gelöst.

Ich schätze - bin mir nicht sicher, muss noch diverese Tests durchführen - dass es daran lag, dass der Peer zyklisch "Hallo" an den Übermittler geschickt hat - damit waren die erzeugten Löcher wieder gestopft, bzw. nur für den Übermittler geöffnet. Da muss man echt vorsichtig sein.

Ich bin aber glücklich darüber, dass es nun klappt ^^

Edit: Geplant ist evt. ne P2P-Filesharing Toolchen, wo Torrenting - Elemente vorkommen werden.

Auf Anfrage veröffentliche ich mal diese kleine "Demo"~.

Es ist theoretisch nicht zu 100% stabil, jedoch bug-free.
Stabil im Sinne von - ich evaluiere z.B. die Anzahl der Bytes, die angekommen sind, nicht ordentlich..
Es reicht für den Test!

Edit:
- Der Tracker ist der "Übermittler".
- Probiert zunächst einmal, dass zu kompilieren - dann wird der Compiler an die Stelle springen, wo Änderungen vorgenommen werden müssen:
IP und Port Daten des Trackers müssen angegeben werden
- Der Port beim Tracker muss gefowardet sein, damit es von außen auch erreichbar ist
- die Peers müssen an sich nichts großartiges tun, einfach an 2 Kollegen hinter 2 verschiedenen NATs schicken und <optimalerweise gleichzeitig!> ausführen lassen (time-outs werden nicht gehandelt - das hier ist wirklich nur eine sehr simple Variante ~hence Demo)

Paper (wichtige Punkte: 2.1 & 3)

Du musst auch bei einigen Routern/Firewalls aufpassen, wenn du von privilegierten Ports sendest.
Meine Fritzbox mochte das überhaupt nicht und hat die Pakete gnadenlos blockiert.

Danke

war nicht mal E Mule oder so mit Delphi programmiert? Da gibts sicher Sourcen.

Zitat von ddcool:

Du musst auch bei einigen Routern/Firewalls aufpassen, wenn du von privilegierten Ports sendest.
Meine Fritzbox mochte das überhaupt nicht und hat die Pakete gnadenlos blockiert.

Ja, das ganze funktioniert ja auch nicht zu 100%.
Da müsste ich halt Spezialfälle berücksichtigen.. Das ganze muss halt noch richtig geplant werden, soweit bin ich noch nicht ^^
Ich spiel gerade noch mit der Technik rum, bis ich etwas Stabiles hab.