# TCP verbindung hinter NAT



## hemeroc (16. Feb 2010)

Hi Leute,

ich habe folgendes Problem:

_"Person A"_ und _"Person B"_ sitzen hinter einem NAT und wollen beide miteinander per TCP kommunizieren.
Sprich _"Person A"_ öffnet einen Server und _"Person B"_ möchte sich zu diesem verbinden.
Ich habe zwar schon einige lösungsansätze die mir aber alle nicht unbedingt gefallen wenn ihr wollt kann ich die zwar posten möchte euch aber in eurer kreativität nicht einschränken ^^

Alle Ideen sind willkommen.
LG Hemeroc


----------



## HoaX (16. Feb 2010)

Ports weiterleiten, alles andere sind nur Tricks die nicht zwangsläuftig funktionieren werden.

Was hat unsere Kreativität mit vorhandenem Wissen zu tun? Das ist ehr Energieverschwendung wenn jetzt 10 Leute über etwas nachdenken was du bereits gelöst hast ...


----------



## hemeroc (16. Feb 2010)

PortForwarding is genauso ein "Trick" weil du dazu zugang zum Router brauchst. ^^
Ich wollte einfach vermeinden das ich wenn ich Technologien wie STUN vorschlage oder das verwenden eines MainServers dann nurnoch über diese disskutiert wird.
Aber wenn du möchstes folgende Ideen hatte ich bis jetzt:

STUN //ist wie der name schon sagt für udp geeignet und kaum für tcp
Globaler Sever über den alles läuft //verursacht auf dem server recht viel traffic
Connection Server (die user verbinden hin, die connection wird dann weitergereicht) //wäre die beste lösung allerdings keine ahnung ob und wie sowas gehn könnte.
Jede Lösung bei der der User nichts an seinem Router ändern muss ist willkommen. Mir ist schon klar, dass das alles dann "Tricks" sind das problem ist nur das viele user keinen Zugang zu ihren Routern haben und ich spreche nicht von HomeRoutern! In der Uni sitz ich beispielsweise auch hinter einem NAT und da kann ich keine Ports freigeben.

LG Hemeroc


----------



## HoaX (16. Feb 2010)

Es gibt noch TCP hole punching - Wikipedia, the free encyclopedia

Portweiterleitung ist in meinen Augen kein Trick, denn genau dafür vorgesehen.
In einem Uni-Netz wirst du mit großer Wahrscheinlichkeit mit keiner der Möglichkeiten erfolg haben direkt mit den Clients untereinander zu kommunizieren.


----------



## hemeroc (16. Feb 2010)

Deshalb auch meine Ideen mit einem "Globalen Server" oder einem "Connection Server".

Das Problem ist, dass das Programm anwenderfreundlich sein muss und damit meine ich nicht das du es bedienen können sollst.
Eher meine ich damit das jemand der sich wirklich nicht gut mit computern auskennt es bedienen können muss. Sprich eine Anleitung wie "und jetzt richten sie auf ihrem Router das port-forwarding ein" sind nicht akzeptabel für meine Zielgruppe.

BTW: wie kommst du darauf das es in uni Netzen nicht gehn soll??? also bei uns ist es auf jedenfall kein problem per icq files zu versenden oder ähnliches (icq-file-transfer geht nicht über den icq-server sondern direkt von client zu client).

LG Hemeroc


----------



## HoaX (16. Feb 2010)

Was ist für dich der unterschied zwischen deinem "Globalen Server" und "Connection Server", für mich ist das beides das selbe.

Klar kann man auch in der Uni Dateien senden und empfangen, aber eben nicht zwangsläufig _direkt_.

Wenn dus dem Nutzer einfach machen willst dann brauchst du noch nen Server im Internet zur Vermittelung.


----------



## Empire Phoenix (17. Feb 2010)

Also der mein uni router ist auf jeden fall sehr liberal, einfach nen paar Upd packet aus den port den man bracht knallen, dann leitet der den an einen weiter wenn den niemand anders beutzt. 

(Ein Glück das man bei Udp keine Verbindungen hat, nur desshalb geht das, der router gibt schlicht den ersten clienten auf dem port. Dieses bleibt solange bestehen wie die letzten Packete x sekunden her sind. Viele Heimrouter haben dieses Verhalten übrigens auch so als tipp)

Jetzt bracht man nur noch den "Connection Server" sprich der vermittelt die Clients die daraufhin versuchen entsprechende löcher in ihre nat zu ballern.


----------



## hemeroc (17. Feb 2010)

HoaX hat gesagt.:


> Was ist für dich der unterschied zwischen deinem "Globalen Server" und "Connection Server", für mich ist das beides das selbe.
> 
> Klar kann man auch in der Uni Dateien senden und empfangen, aber eben nicht zwangsläufig _direkt_.
> 
> Wenn dus dem Nutzer einfach machen willst dann brauchst du noch nen Server im Internet zur Vermittelung.



Wie gesagt bei uns funktioniert die direkte dateiübertragung (beispielsweise gehen P2P clients in unserer uni) keine ahnung wie das bei euch is.

Ich weiß natürlich das ich einfach nen Server dazwischen legen kann der dann ein unglaublich hohes traffic aufkommen haben wird => sehr unpraktisch und teuer (globaler server)

und das sollte auch der unterschied zwischen einem connection und einem globalen server sein.
also ist es möglich das 2 clients aktiv eine verbindung zu einem server aufbaun und die verbindung dann sozusagen weitergereicht wird. sprich das der server in der mitte nur zum aufbau der verbindung verwendet wird. (mir fällt keine methode ein das zu erreichen und ich weiß auch nicht ob es überhaupt geht deshalb frag ich ja, das wäre dann ein connection server)


----------



## Empire Phoenix (17. Feb 2010)

Tcp, geht nicht Upd mein post lesen


----------



## hemeroc (17. Feb 2010)

Empire Phoenix hat gesagt.:


> Tcp, geht nicht Upd mein post lesen



Sicher das TCP nicht geht? => TCP hole punching - Wikipedia, the free encyclopedia

nur steht da recht wenig wie ich finde weiß jemand vielleicht etwas bessere literatur dazu gerne auch in englisch ^^


----------



## Gast2 (17. Feb 2010)

hemeroc hat gesagt.:


> Sicher das TCP nicht geht?



ja ... TCP geht nicht mit Java


----------



## hemeroc (17. Feb 2010)

mogel hat gesagt.:


> ja ... TCP geht nicht mit Java



Kannst du diese Annahme auch erläutern? Ich wüsste gerne warum es nicht geht.
Und wenn dann meinst du TCP-hole-punching denn die aussage das TCP mit java nicht geht wage ich doch anzuzweifeln.


----------



## tuxedo (17. Feb 2010)

Jepp, geht um das TCP hole-punching. Und das geht deshalb nicht, weil Java keinen so low-level zugriff auf TCP erlaubt wie man es wohl dafür bräuchte.


----------



## hemeroc (17. Feb 2010)

tuxedo hat gesagt.:


> Jepp, geht um das TCP hole-punching. Und das geht deshalb nicht, weil Java keinen so low-level zugriff auf TCP erlaubt wie man es wohl dafür bräuchte.



Genau das ist der Grund warum ich nach besserer Literatur gefragt habe. Leider weiß ich nicht wie low-level der Zugriff auf tcp für tcp-hole-punching sein muss. Vielleicht könntest du es ein wenig erläutern oder mir deine Quellen sagen ich les auch gern selber ^^

LG


----------



## tuxedo (18. Feb 2010)

Der Wikipedia-Artikel zu TCP Holepunching erklärt das eigentlich recht gut. Wenn das nicht reicht und TCP-Grundlagen fehlen kannst du dir das RFC Dokument zu TCP anschauen (google hilft). Alles in allem stellt sich aber einem die Frage warum du dir seitenlange Dokumente antun willst um etwas zu verstehen das mit Java so nicht machbar ist.

Du hast in meinen Augen exakt 3 Möglichkeiten:

1) Nimm UDP-Holepunching
2) Schau nach UPnP Libs die, sofern es der Rouzer zulässt und unterstützt, die Portweiterleitung im Router automatisch konfigurieren (Azureus und Co. machen das z.B. so)
3) Mach ne kleine Anleitung die dem User das einrichten der Portweiterleitung erklärt.

Variante 1 wär die userfreundlichste. Ist aber mit nicht sonderlich einfach wenn man wirklich alle Hindernisse berücksichtigen will (selbst Skype, was UDp holepunching benutzt hat seine Grenzen)

Variante 2 und 3 haben halt so ihre tücken. Aber sind gang und gebe wenn es darum geht TCP Services hinter einem Router etc. anzubieten.

- Alex


----------



## hemeroc (18. Feb 2010)

Warum ich seitenlange RFCs lese? Weil ich etwas lernen möchte. Weil ich die Thematik interessant finde. Es hat einfach etwas mit dem Grundsätzlichen Verständniss zu tun es muss ja ned alles mti Java gelöst werden. Schon klar das jede Sprache ihre Grenzen hat deshalb gibt es ja zum Beispiel auch JNI.

UDP-hole-punching verwenden wir ich wollte nur eben einen weg für tcp.

Ich bin gerade auf der suche nach einer guten UPnP Llibrary wenn ich keine finde werde ich das wohl selbst implementieren.

LG


----------



## Empire Phoenix (18. Feb 2010)

Diese lösungen wirste kaum in offizielen Referenzen finden, weil sie halbwegs krimmineller missbrauch von Protokollen aus dem 70er Jahren sind für Problemstellungen die es damals nie gab. (Im hinterkopf tcp/ip/udp waren für 6-9 Rechner ausgelegt mit vielleicht 200 im hinterkopf, an NAT's wurde damals nicht gedacht (vom internet mal zu schweigen))


----------



## Gast2 (18. Feb 2010)

hemeroc hat gesagt.:


> Warum ich seitenlange RFCs lese? Weil ich etwas lernen möchte. Weil ich die Thematik interessant finde.


dann wechsel die Sprache ... wenn es um Low-Level Programmierung ist Java definitiv falsch ... mit .NET kannst Du ads nur wenn Du Masochist bist und C++/CLI verwendest ... ansonsten rate ich Dir zu nativem C++



> Schon klar das jede Sprache ihre Grenzen hat deshalb gibt es ja zum Beispiel auch JNI.


man kann sich auch sinnlos Arbeit machen


----------



## Kr0e (18. Feb 2010)

Hi Leute, ihr liegt leider alle falsch 
Es gibt sehr wohl TCP Hole punching über TCP für JAVA:

STUNT: NAT TCP Traversal

Klappt aber halt nicht zwangsläufig aber bei neuen Routern garkein Ding... Und mal ehrlich... Bei den Providern bekommt man alle 2 Jahre nen Neuen 

Gruß,
Chris


----------



## Empire Phoenix (19. Feb 2010)

You need to install WinPcap.

Also ich garantiere das die hälfte aller Virenscanner abgeht, weil das ding auch zum Sniffen missbraucht werden kann/wird.


----------



## Gast2 (19. Feb 2010)

Kr0e hat gesagt.:


> Es gibt sehr wohl TCP Hole punching über TCP für JAVA:


nein ... Du wechselt damit auf die native Seite und verwendest JNI ... mit Java geht das nicht


----------



## Kr0e (19. Feb 2010)

Ja mein Gott, wofür gibt es JNI ? Macht doch keinen SINN jede Funktion auf JEDE Sprache anzupassen. Genau das macht doch Java so flexibel ?! Stichwort OpenGL. Gibet für Java auch nur durch native Bibliotheken. Aber einfach generel zu sagen "Nö, das mit "pure Java" nicht möglich ist ja auch nciht ganz richtig. Ich meine durch so eine Erbsenzählerei wird doch der Ersteller des Threads nur verwirrt. Etwas wie "theoretisch wäre das möglich" wäre da schon passender.

Gruß,
Chris

Und nochwas: Warum sind denn native Libs unerwünscht ? Solange es sie für die wichtigsten Plattformen gibt...


----------



## tuxedo (19. Feb 2010)

WinPCap setzt eine DLL vorraus. Und die wird mittels JNI angebunden. 

Java hat von Haus aus keinen so low-level Zugriff auf TCP wie man es für TCP hole-punching bräuchte.


----------



## Gast2 (19. Feb 2010)

Kr0e hat gesagt.:


> Ja mein Gott, wofür gibt es JNI ?


für Leute die Langeweile haben, sich gerne selber geiseln oder genau wissen was sie da machen ... was Du an der ganzen Sache vergisst sind die elendich lange Strukturen die für solche Aktionen benötigt werden



> Genau das macht doch Java so flexibel ?! Stichwort OpenGL. Gibet für Java auch nur durch native Bibliotheken. Aber einfach generel zu sagen


in dem Moment wo Du JNI verwendest machst Du Java unflexibel ... Dein Programm läuft nur noch genau auf diesem BS wo Du die JNI zu erstellt hast ... soll es auf einem anderem BS laufen, hast Du schon mal die doppelte Arbeit



> "Nö, das mit "pure Java" nicht möglich ist ja auch nciht ganz richtig.


natürlich ist das korrekt ... aber da war Tuxedo schon so freundlich



> Ich meine durch so eine Erbsenzählerei wird doch der Ersteller des Threads nur verwirrt. Etwas wie "theoretisch wäre das möglich" wäre da schon passender.


nein "theoretisch ja" ist verwirrender als ein "praktisch nein" ... der OP will etwas lernen ... dann kann er gleich eine andere Sprache lernen - die Welt besteht aus mehr als nur Java (für die die es nicht wissen)


----------



## Kr0e (19. Feb 2010)

Wieso praktisch nein ?! Lass doch den Threadersteller selbst entscheiden, ob JNI ein Problem für ihn ist. Es gibt nunmal Dinge die einfach OS-abhängig sind. Im Gegenteil, ich finde JNI ist ziemlich genial. Sehr viele wichtige Dinge lassen sich praktisch nur über JNI regeln.

Ne andere Programmiersprache zu lernen hilft da nix... Jede Sprache hat ihre Probleme. Wenn du ihm sagst "JA nimm C dann hasse mehr Hardwarezugriff..."... dann ist das gut und schön aber TCP Hole Punching wäre sicherlich ein kleiner Teil seines Projektes. Sprich für den ganzen Rest stößt man dann weider auf Nachteile von C. Du kannst z.B. kein Multimediaprogramm ohne JNI machen. Für Videodekodierung oder 3D gibt es nix vergleichbar Gutes in pur Java. Und es ist eben garnicht nötig. Ist doch prima, wenn jemand in C ne Lib gemacht hat und sie über JNI auf der Java Welt bereitstellt. Warum also nicht nutzen!

Verstehe nicht woher deine Abneigung gegenüber JNI herkommt, echt nicht.

PS: Kann ja nicht an der Geschwindigkeit liegen... Ein JOGL Programm ist genauso schnell wie ein C OpenGL Programm.


----------



## tuxedo (19. Feb 2010)

Um es nochmal auf den Punkt zu bringen:

Es schickt sich nicht, sofern es nicht absolut notwendig ist, irgendetwas für irgendwas zu vergewaltigen.

In diesem Beispiel geht's um TCP holepunching. Nicht dass TCP holepunching nicht allein schon ne vergewaltigung des System ist, nein. Es schickt sich auch nicht jemandem dann eine Lib anzuraten die a) nicht ohne native Eingriffe funktioniert, b) seit geraumer Zeit nichtmehr gepflegt wird.

Das potential an Fehlerquellen und Problemen die damit einhergehen ist deutlich höher als die, wenn man eine native Java Lösung zu benutzt/findet.

Allein schon der Testaufwand den man mit JNI auf einmal hat. Da gibts Windows, Linux, 32bit, 64bit, ... Das gibt recht schnell ne große Test-Matrix. 
Und wenn es nur mit Windows laufen soll: Hey, warum dann Java?! Es gibt doch genug andere Möglichkeiten schicken und schnellen Code zu schreiben ... 

Ich weiß echt nicht woher deine liebe zu JNI kommt ???:L

- Alex


----------



## Kr0e (19. Feb 2010)

Nunja, JNI hat Java überhaupt ein OpenGL API zu verdanken. OpenGL ist ein wichtiges Feature bei Java. Ich meine Dank JNI kann man prinzipiell jede bereits existieren Library über Java ansprechen. Das ist schon ne gewaltige Sache, oder nicht ? Na klar, JNI bringt Stress mit sich (IM Bezug auf die TCP Hole Punching Lib geb ich dir da sogar Recht, dass es vermutlich mehr Stress macht als Vorteile bringt...), aber auf anderen Bereichen kann doch garnicht auf JNI verzichtet werden (DA es einfach keine Alternative gibt!). Und ja, vermutlich wäre eine gute UPnP Library besser. Aber es gibt TCP Hole Punching Libs für Java. Mehr wollte ich damit nicht sagen. Und sie direkt als unbrauchbar zu deklarieren, nur weil sie JNI nutzt, finde ich auch fragwürdig. Kommt doch immer auf die eigenen Bedürfnisse an.

Gruß,
Chris


----------



## tuxedo (19. Feb 2010)

An manchen ecken und enden ist JNI nicht mehr weg zu denken (OpenGL). Aber da ist das noch einigermaßen legitim. 

JNI als allheilmittel darzustellen halte ich allerdings für den falschen Weg. 

- Alex


----------



## hemeroc (19. Feb 2010)

mogel hat gesagt.:


> der OP will etwas lernen ... dann kann er gleich eine andere Sprache lernen - die Welt besteht aus mehr als nur Java (für die die es nicht wissen)



Sorry, aber das is so eine typisch sinnfreie Aussage. Es ist einfach dieses Typische
Frage: Ich habe ein Problem das ich mit A lösen möchte.
Antwort: Nimm doch B.​
Ich habe Gründe dafür das ich A verwenden muss/will (in meinem Fall Java).
Ich kann genug andere Programmiersprachen was auch einer der Gründe ist warum ich JNI in meine Überlegungen mit einbeziehe. Warum man allgemein JNI verwendet finde ich relativ einfach zu beantworten. Wieviele andere Sprachen die gute Multiplattform Unterstützung bieten kennst du? Und es is immernoch einfacher 3-4 JNI libraries zu warten und eben ein Java Programm als 3-4 komplette Programme!

LG Hemeroc

EDIT: niemand hier hat behauptet das JNI ein Allheilmittel ist, es hat sicher seine Daseinsberechtigung und zum einen habe ich am Anfang ja erwähnt das die Lösung zum einen nicht unbedingt mit TCP-hole-punching gehen muss zum anderen wollte ich möglichst viele kreative Ideen und Anregungen. Auf jeden Fall DANKE euch allen für eure Mithilfe.


----------

