TCP über UDP Verbindung?

[_-`avaj´-_]

Hallo alle zusammen,
Ich hätte forgende Frage:

Ist es theoretisch möglich eine Verbindung mit UDP Hole Punching zwischen zwei Computern aufzubauen und dann über diese Verbindung mit TCP zu arbeiten?
Also im Prinzip erkennt ja die NAT (bei UDP) welcher Port zu welchem Computer im Netztwerk gehört, also sind die Computer auch von außen über diesen Port zu erreichen und damit sollte doch auch TCP möglich sein...?

Dabei stellen sich jetzt aber 2 Probleme:
1. Der Socket vom UDP Verbindungsaufbau behindert den Port und
2. UDP arbeitet mit Paketen und TCP mit Streams und ich weiss nicht ob die NAT auch eingehende Strams an den jew. Port weiterleitet...?

Also das ganze ist nur eine Idee, da ich das Arbeiten mit UDP nicht alzu konfortabel finde (Paketverlust etc.) und Streams auch z.B. zum Versenden von Datein besser wäre...

Und bevor jetzt wieder alle kommen und sagen: Warum arbeitest du dann nicht einfach mit TCP?
Weil ich über das Internet will und zwar ohne Portfreigaben oder sonstigem Zeugs, das der User selber einstellen muss...

 

[Kr0e]

Dieses Thema gabs schon sehr oft hier.


TCP über UDP ist nicht möglich. Du kannst dir aber sowas wie TCP auf Basis von UDP nachbauen.

Da gibts sogar schon nen Standard, nennt sich Reliable UDP und wird z.b. bei RakNet implementiert.
Klappt ganz gut, definitiv besser, als wenn man sich alles selbst überlegt.


TCP Nat punching geht auch, ist aber bei weitem komplexer und geht nicht bei allen Routern. Und selbst wenn, dann nicht mit Java. Dafür braucht man min. Zugriff auf Rawsockets.
Natürlich kannst du dich in C++ austoben und die Lib für Java mittels JNA JNI zugänglich machen.

Allerdings gibt es für C/C++ bereits Lösungen. Google mal nach STUNT.

Fazit: Lass es, es ist äußert haarig und selbst wenn mans hinbekommt, ist es entweder nicht performant oder klappt nicht bei allen Routern.


Die User sollen endlich mal lernen, wie man Ports freigibt!

 

[Gast2]

Moin,

alles andere ja - aber das hier ...

Die User sollen endlich mal lernen, wie man Ports freigibt!

dann lerne endlich mal wie man einen Ölfilter wechselt - sorry, der musste sein

hand, mogel

 

[Kr0e]

Das ist was anderes. Ich verlange nicht, dass der User ne Grafikkarte wechseln soll. Bloß auf eine Webseite connecten und ein paar Knöppe umstellen. Um dein Sinnbild zu vervollständigen, ich weiß wie Nebelscheinwerfer angehen

Ich weiß, dass das nicht passieren wird. Wie auch, in Zeiten wo Software Null Selbstdenken erfordert, bzw. dies das Ziel der Ziele ist. "Intuitive Bedienung".

Ist halt meine Meinung. Wäre doch schön, wenn die Leute sich wenigstens etwas mit dem auskennen was sie tagtäglich benutzen.


--EDIT--

Bei meiner alten Arbeitsstelle war man schon froh, wenn die Leute den Druckerbutton finden konnten. Und Gott war das Geschrei groß, wenn sie mal den Explorer aus Versehen geschlossen haben und nciht wussten wie der wieder angeht (Der war damals immer im Autostart drin). "S***** Technik"...
Leute die nicht wissen, wie man Ports freischalten, haben es nicht verdient, PRogramme zu benutzen, die das erfordern. So einfach is das (Oder anders formuliert, Leute die nicht Google benutzen können)

 

[_-`avaj´-_]

@Kr0e
Sorry aber ich habe leider kein Thema gefunden in dem das schon angesprochen wurde aber danke für deine Antwort...
Na dann arbeite ich halt weiter mit UDP... für meine jetztigen Spiele (noch) nicht allzu störend

Leute die nicht wissen, wie man Ports freischalten, haben es nicht verdient, PRogramme zu benutzen, die das erfordern. So einfach is das (Oder anders formuliert, Leute die nicht Google benutzen können)

Stimmt
Aber wenn man es halt verlangt, dann benutzt deine Programme halt niemand weils allen zu blöd is -.-
Wie wäre es eigentlich mit ein paar standart Portfreigaben? Die NAT legt für jeden Computer im Netztwerk einen standart Port an, den dann Programme nutzen können, diese müssen dann halt immer zwischen den Programmen verwaltet werden...

 

[Kr0e]

Stimmt
Aber wenn man es halt verlangt, dann benutzt deine Programme halt niemand weils allen zu blöd is -.-

Total agree. Das Dilemma eines Entwicklers =(

 

[Empire Phoenix]

das pirnizp hat zumindest noch niemand den linux entwlicklern gesagt ^^, XD da ist es immernoch so das man wissen muss was man tut. (schöne welt)

 

[TCPoverUDP]

Das Thema TCP-over-UDP gab es hier tatsächlich schon ein paar mal und wurde auch das eine oder andere mal mehr oder weniger erfolgreich umgesetzt, aber wirklich performant konnte man die wenigsten nennen.

Aber um vielleicht erstmal auf etwas hinzuweisen :

Wenn du mit UDP-Hole-Punching eine UDP-Verbindung offen hast, dann hindert dich das doch nich daran mit TCP über die selbe Port-Nummer zu arbeiten, denn TCP/1337 ist etwas völlig anderes als UDP/1337 und kommt sich desshalb auch nicht in die Quere.

Auch heißt es nicht STUNT sondern nur STUN : Session Traversal Utilities for NAT (früher auch : Simple traversal of UDP through NATs). Das ganze ist mitlerweile ein etablierter Standard und funktioniert daher auch mit allen gängigen Router-Modellen. Viele bekannte Spiele nutzen diese Technik (keine namentliche Nennung) sowie teilweise auch gewisse Kommunikations-Applikationen.

Zum pauschalen "Leute, lernt wie man Ports frei gibt" rate ich eher ab. Grundsätzlich sollte Port-Forwarding nur bei TCP-Servern notwendig sein. Als Client kann es einem eh egal sein und UDP kann man wie ja schon erwähnt wurde über STUN abwickeln. Außerdem ist eine Software die es für den Betrieb vorraussetzt das Ports nach außen hin geöffnet werden ein extremes Sicherheitsrisiko.

Und die Idee mit "NAT legt standard Ports für Clients an" ist ziemlicher Mist und wäre auch gar nicht skalierbar. Es würde eh nur passieren wenn sich der "Client" beim NAT meldet, was in der Regel nur durch DHCP passiert. Wenn man aber mit statischen Adressen arbeitet nutzen viele Router das ARPing nicht mehr richtig aus und wissen halt nur noch lediglich welche IP mit welcher MAC an welchem PORT angeschlossen ist. Das weitere Problem wäre : was passiert wenn du mehrere Router hintereinander hängst ? Der "höhere" Router würde nur einen Port an seinen "Client" vergeben. An diesem hängen aber vielleicht 10 weitere Clients, wesshalb also der "nidrigere" Router beim "höheren" weitere Ports anfordern müsste, die dieser vielleicht gar nicht mehr hat. Zusätzlich kommt das jede ausgehende Verbindung ebenfalls in der NAT eingetragen wird und somit die verfügbare Menge der "freien Ports" weiter singt je mehr Verbindungen nach außen aufgebaut werden. Alles in allem so nur ziemlich schlecht bis überhaupt nicht umsetzt bar. Alleine die Idee ist schon ziemlich wirr.

Es gibt zwar noch die Möglichkeit "UPNP" die auch von vielen moderene Geräten unterstützt wird und standardmäßig auch aktiviert ist, allerdings greift auch hier : NICHT ALLE. Ich z.B. habe in meinem Router UPNP deaktiviert weil ich nicht will das irgendeine wildfremde App mal eben irgendwelche Ports in meinem Router öffnet und ich davon nichts mitbekomme. An sich eine super Erfindung für Trojaner. Praktisch halte ich aber eher weniger was davon.


Man kann über das was bis jetzt alles schon gefallen ist wunderbar diskutieren, um aber beim Topic zu bleiben : grundsätzlich JA, es ist möglich ... andererseits aber : mit viel Aufwand verbunden. Ob der Aufwand gerechtfertigt ist für das was man am Ende will muss jeder selbst entscheiden.

 

[bERt0r]

Vielleicht hilft das weiter: TCP Hole Punching Sockets

 

[Kr0e]

Komisch.... "TCPoverUDP":

Dein ganzes Statement ist eigentlich im Endeffekt pro Portfreigabe, da du ja mit bekommen willst wenn was geschieht.

Im Endeffekt: Lass es die Leute selbst freigeben, bzw, versuch UPNP. Wenns dann nich klappt, pech gehabt -> Torrents !

 

[tuxedo]

Die User sollen endlich mal lernen, wie man Ports freigibt!

Man sollte viel lieber drauf drängen IPv4 und damit NAT zu verdrängen. Dann fällt die klassische Port-Weiterleitung weg ;-) Okay, dann muss man sich mit Firewall beschäftigen. Aber da hat man wenigstens kein verwirrendes NAT Problem mit den vielen IPs ...

- Alex