(TCP) Verbindung ohne Portforwarding

[Network]

Hi,

habe Google durchsucht und die Javadoc, finde leider nichts darüber.
Gerne würde ich eine TCP-Verbindung aufbauen ohne Ports öffnen zu müssen. Beiden Clienten ist aber die locale IP bekannt.

Im Grunde sollen sich die Clienten mithilfe eines Servers miteinander verbinden. Der Server übergibt dann einfach die IP und locale IP(?) Und die Clienten verbinden sich dann zueinander direkt, somit hat der Server selbst dann nicht so eine große Auslastung.
So jedenfalls die Theorie.

Sockets nehmen aber nur den Port entgegen... Ports sind doch nur dazu da um auf unbekannte andere Clienten zu warten, aber theoretisch kennen sich die beiden ja bereits.

Vielen Dank
Gruß
Net

PS: Ein Googlebegriff würde vieleicht auch helfen, weil ich nicht genau weiss nach was gesucht werden muss. Wenn es dafür überhaupt etwas zu suchen gibt.

 

[gp]

Es geht nur ueber Ports - warum auch nicht???

Gesendet von meinem GT-P7501 mit Tapatalk 2

 

[TheDarkRose]

Wie gesagt, sie dir UDP Hole Punching an. Das Prinzip funktioniert etwas komplizierter auch mit TCP.

Gesendet von meinem Nexus 7 mit Tapatalk 2

 

[troll]

TCP Hole Punching ist so mit reinem java nicht möglich ... dafür braucht man eine spezielle zusatz-lib die den os-stack anzapft und manipuliert ... denn bei TCP spielen auch noch dessen zusätzliche header die UDP nicht hat eine rolle ... und hier ist gerade der order-header ganz wichtig ...
außerdem muss man richtig mit den status-flags arbeiten ... sonst bricht die verbindung zusammen oder kann garnicht erst aufgebaut werden ..


@TO
entweder port forwarding oder UDP mit Hole Punching ... anders geht es nicht (außer vllt über einen server)

 

[gp]

Auch UDP arbeitet mit Ports, auch wenn Tools das nach aussen kapseln moegen.

guenter via tapatalk

 

[TheDarkRose]

Auch UDP arbeitet mit Ports, auch wenn Tools das nach aussen kapseln moegen.

Hat irgendeiner von uns gesagt, das man keine Ports braucht?

 

[Gast2]

Gerne würde ich eine TCP-Verbindung aufbauen ohne Ports öffnen zu müssen.

unterscheide bitte zwischen Portweiterleitung (DSL-Router) und Port des Sockets (letzteren brauchst Du 100%)

Beiden Clienten ist aber die locale IP bekannt.

wenn beide Rechner bei Dir stehen, dann brauchst Du keine Portweiterleitung.

Im Grunde sollen sich die Clienten mithilfe eines Servers miteinander verbinden. Der Server übergibt dann einfach die IP und locale IP(?) Und die Clienten verbinden sich dann zueinander direkt, somit hat der Server selbst dann nicht so eine große Auslastung.

Fall A - beide Clients kommunizieren über den Server, Du hast einen Root-Server im Internet. Insgesammt die einfachste Variante
Fall B - beide Clients kommunizieren direkt, beide Clients haben einen eigene DSL-Anschluß. Ohne Portweiterleitung geht da nichts

Ports sind doch nur dazu da um auf unbekannte andere Clienten zu warten, aber theoretisch kennen sich die beiden ja bereits.

nein - nur Du kennst beide Rechner. An der Netzwerkkarte kommen nur Bits an. Und kein Bit hat einen eindeutigen Absender . Damit kennen sich die Rechner nicht.

erkläre mal lieber was Du machen willst und wo die Rechner physkalisch stehen

 

[gp]

Hat irgendeiner von uns gesagt, das man keine Ports braucht?

Die Frage war: geht es ohne Ports. Ob die Frage richtig formuliert war ist eine andere Sache Forwarding ist auch im Gespräch

guenter via tapatalk

 

[Network]

@gp
Die Überschrift lautet "Verbindung ohne Portforwarding" und die Problemstellung besagt "[...] ohne Ports öffnen zu müssen.".
Wie heißt die Fragestellung richtig? Dann weiss ich es für die Zukunft

@TheDarkRose
Das ist doch mal ein Stichwort, gegoogelt und gefunden. Danke

@mogel
Rechner <-> Router <-> [Internet] <-> Router <-> Rechner

Aber UDP-HolePunching sieht bereits nach dem richtigen aus und mithilfe von "troll"s Tipp weiss ich auch nach was genau gesucht werden muss wenn man es für TCP umgesetzt haben will.
TCP selbst ist mir ehrlich gesagt nicht so wichtig wenn es zu kompliziert damit wird. Ist halt schön wenn man mal eine komplett sichere Verbindung hat.
Gerade über Edge gehen häufig viele Daten über UDP verloren, fällt mir hin und wieder auf bei einem Videostream.

Danke
Net

 

[Kr0e]

Hab mich damit auch viel beschäftigt...

TCP Hole Punching IST mit Java möglich. Ist sogar in Form einer Library komplett fertig anwendbar.

UCE RMI - TCP Hole Punching Sockets

TCP hole punching kann man über verschiedene Arten realisieren. Manche davon gehen nicht mit Java, das stimmt. Z.b. die, wo man die Packete direkt verändern muss. Da braucht man dann in der Tat etwas low-leveligeres.

UDP Hole Punching ist im Vergleich recht trivial, allerdings ist das Nachbauen von TCP über UDP haarig. In dem FAll würde ich RUDP (Reliabe UDP) empfehlen. Natürlich sind die meisten Impl. nicht mal ansatzweise vergleichbar mit TCP. Tcp ist einfach zu alt und zu gut optimiert. Rechne hier also mit Abstrichen...

ABER:

Ich persönlich würde nichts von beiden nehmen. Das Hauptproblem ist, das Hole Punching nur in gewissen Szenarien funktioniert. Es kommt auf die Netzwerkstruktur an. Große Firmennetze z.b. verhindern sowas häufig. (Fazit: Wer sind deine Kunden ? Firmen oder Heimuser mit bloß einem NAT dazwischen)

TCP Hole Punching ist im Schnitt schwieriger zu realisieren als UDP HP. Sprich viele Router machen das eifach nicht mit.


LÖSUNG ?

Nun ... UPnP ist eine Idee... NAT-PMP ist eine weitere sehr gut funktionierende Sache. Bei beiden Lösungen müssen die User IM IDEALFALL ebenfalls keine Ports freigeben, allerdings müssen die Router einsprechend konfiguriert sein.


FAZIT:

Es gibt keine Lösung die ALLE Probleme abdeckt. Überleg dir, was du machen willst und wähle die entsprechende Lösung. Wenn deine Anwendergruppe sowieso eher high-level wäre... Dann kann man auch Portfreigabe erwarten. Und heuzutage können selbst 10 Jährige Ports für Minecraft oder CSS Server öffnen.....


PS: Bei so exotischen Sachen wie TCP HP muss man bei Universitäten schauen... Dort werden solche Probleme meistens in Form in Master/Doktorarbeiten gelöst. Nicht alles findet man direkt bei Google

 

[Network]

Hab mich damit auch viel beschäftigt...

TCP Hole Punching IST mit Java möglich. Ist sogar in Form einer Library komplett fertig anwendbar.

UCE RMI - TCP Hole Punching Sockets

Danke, ja das hatte ich auch per Google gefunden (Erster Eintrag). Gut zu wissen, dass es eine Empfehlung dafür gibt.

UDP Hole Punching ist im Vergleich recht trivial, allerdings ist das Nachbauen von TCP über UDP haarig. In dem FAll würde ich RUDP (Reliabe UDP) empfehlen. Natürlich sind die meisten Impl. nicht mal ansatzweise vergleichbar mit TCP. Tcp ist einfach zu alt und zu gut optimiert. Rechne hier also mit Abstrichen...

Wo kommt jetzt RUDP plötzlich her? Zusammenhang?
Also beim Wort RUDP fallen anscheinend bereits Brieftauben vor Schreck vom Himmel wenn sie das hören, stand auf irgendeiner Internetseite beim durchforsten von Google.

LÖSUNG ?

Nun ... UPnP ist eine Idee... NAT-PMP ist eine weitere sehr gut funktionierende Sache. Bei beiden Lösungen müssen die User IM IDEALFALL ebenfalls keine Ports freigeben, allerdings müssen die Router einsprechend konfiguriert sein.

-.- Klasse Apple musste mal wieder das Rad neu erfinden, hatte ich nicht gewusst... damit fällt UPnP also schlussendlich ganz aus den Überlegungen weg. Muss ich ja gleich zwei Technologien unterstützen für eine relativ kleine Anwendergruppe.

Wenn deine Anwendergruppe sowieso eher high-level wäre... Dann kann man auch Portfreigabe erwarten. Und heuzutage können selbst 10 Jährige Ports für Minecraft oder CSS Server öffnen.....

Tja erwarten ist immer so ein hoch angesetztes Wort.
In meiner Planung hatte ich mir eigentlich eine Art Internet im Internet gedacht, bei der jeder Nutzer einer Gruppe beitreten kann ohne auf einen Server limitiert zu sein, sondern jedem Nutzer beitreten kann und damit automatisch mit jedem anderen Nutzer verbunden wird.

Das würde aber vorraussetzen, dass jeder dieser Nutzer Ports freigibt, damit die Sockets zueinander erst aufgestellt werden können.
Ziel ist die Abschaffung eines zentralen Servers.

Naja ich versuche es jetzt erstmal generelldas umzusetzen und zu schauen wo und wie Hole Punching versagt, dann bietet sich immernoch die Portfreigabe an.

Gruß
Net

 

[Kr0e]

Fast alle seriösen Programme nutzen UPnP oder NAT-PMP. BitTorrent, IM, etc.

UDP HP ist bei Skype etc. natürlich beliebt, aber dein Anwendungsgebiet klingt nach "verlässlicher" Datenübertragung... Also müsstest du dann mit UDP iwie sicher stellen, dass die Pakete wirklich angekommen sind.

RUDP ? Ich hatte da direkt vorweg genommen, dass du ggf. UDP Hole Punching machen könntest und für die sichere Übertragung RUDP nutzt. Ein Protokoll, dass auf UDP aufsetzt und TCP nachbaut.

Für manche Sprachen gibt es Abstraktionen, die UPnP und NAT-PMP und ggf. weitere Techniken zusammenfassen. Mit etwas Glück ist Java dabei.

Ich arbeite allerdings schon lange nicht mehr aktiv mit Java, kann dir also leider spontan nichts empfehlen..

 

[tuxedo]

Es gibt noch eine Lösung: Relay-Server .. Allerdings brauchst du da noch einen Rechner der kein NAT braucht um ins Internet zu kommen ((v)root server, managed server, ...). Das ganze skaliert je nach aufkommendem Traffik nur mit entsprechenden Kosten für ggf. weitere Server. Eines der bekanntesten Anwendungsbeispiele für Relay-Server ist Teamspeak ... Hier steht ein Server zentral im Netz und vermittelt die Pakete zwischen den Clients. Je nach Protokoll und Traffikaufkommen kannst du da sicher einige hundert bis tausend Clients damit bedienen.

Port-Forwarding: Nein, das kann man nicht von allen Zielgruppen vorraussetzen. 10 jährige Mindecraft-Kiddies haben einen ganz anderen Background als irgendwelche Manager die in ihren Büros mit iPhone und iPad hocken und von konfiguration und Co. absolut nix wissen wollen (Einstecken->Starten->Läuft).

Und zuguter letzt:
Wenn UPnP und UDP HolePunching nicht greifen, dann benutzt Skype und Co. auch den Fallback auf einen Relay-Server...

- Alex