Hallo alle miteinander
Mein Problem ist folgendes ich habe ein Netzwerkfähiges Programm geschrieben das im Endeffekt Text (Strings) übers Netzwerk verschickt.
Nun möchte ich das Programm übers Internet lauffähig machen.
Hierzu nutze ich: die UDP-Komponente von Narsen, Delphi 7, diverse Router.
Mein Ansatz: Port forwarding. Das Funktioniert Seher gut ABER und damit kommen wir zu
Mein Problem:
Wie kann ich
a) Ports forwarden in dynamischen Netzwerken (d.H. keine Feste IP im Lokalen Netzwerk
b) ohne an den Router zu sitzen bzw. sein Passwort zu kennen (aber den Exakten Name und die Serien Nummer des Routers)
c) die IP bestimmen die der Rechner im Internet hat (alles ohne davor zu sitzen ^^).

Ich meine Software wie ICQ schafft das doch auch irgendwie oder liege ich da falsch?

P.S. ja ich weiß das sind bösartige fragen ^^ und ziemlich unorthodoxe noch dazu ^^.

Moderiert von Narses: Titel erweitert.

Nö, da liegst du falsch.
ICQ baut nur ausgehende Verbindungen auf.
Versuch mal mit ICQ Dateien zu empfangen, ohne ein Port Forwarding einzurichten.

Und aus deiner Anwendung: Das wär ja grausam, wenn jede x-beliebige Applikation Ports an jedem beliebigen Router freigeben kann -> Sollte (muss?) der Benutzer selber machen.

Xentar hat folgendes geschrieben :

Und aus deiner Anwendung: Das wär ja grausam, wenn jede x-beliebige Applikation Ports an jedem beliebigen Router freigeben kann -> Sollte (muss?) der Benutzer selber machen.

Naja, nicht ganz.
Wenn UPnP aktiviert ist am Router darf eine Software dort einfach einen Port für sich freigeben. Das funktioniert aber nur innerhalb eines Netzwerkes, wenn also ein weiterer Router dazwischenhängt, geht sowas nicht.

Ich selbst habe das so eingerichtet, dass ein Rechner mit Firewall und aktiviertem UPnP nochmal dazwischenhängt. Wenn dort ein Port eingetragen wird, sehe ich das über eine Software, die auf meinem PC läuft und ich kann entscheiden, ob ich diesen Port auch im Router selbst wiederum auf den Gateway-PC weiterleiten möchte, so dass das funktioniert.

Was ICQ und andere Software angeht:
Diese bedienen sich eines Tricks, für den aber ein echter Server im Internet zur Vermittlung gebraucht wird. Wenn du den nicht hast, bleibt dir nur Portforwarding.

Ist dir bewusst, dass ein UDP-Paket ohne weiteres einfach verworfen werden kann und die Reihenfolge von versendeten Paketen beim Empfangen anders sein kann?

Wäre es denkbar, dein Programm mit einem Server im Internet kommunizieren zu lassen? Bspw. WebService via PHP.

Also das UDP Pakete gerne vergessen werden weiß ich ^^
hab ich aber schon abgefangen.
Was den Server anbelangt: Nein, deswegen habe ich ja UDP gewählt ^^

Mein Hauptproblem ist nach wie vor das Port forwading in einen Netzwerk das Dynamische IP Benutzt. Und das ganze sollte dann automatisch (d.H. vom Programm) werden können. Das Problem mit dem Unbekanntem Passwort lässt sich im Notfall lösen.

theChaoS hat folgendes geschrieben :

Was den Server anbelangt: Nein, deswegen habe ich ja UDP gewählt ^^

Was hat ein fehlender Server mit der Entscheidung zwischen TCP und UDP zu tun? Habe ich was verpasst? Broadcast und Server automatisch finden und sowas geht selbstverständlich nur im lokalen Netzwerk.

theChaoS hat folgendes geschrieben :

Das Problem mit dem Unbekanntem Passwort lässt sich im Notfall lösen.

Das Problem ist der Zugriff auf den Router, wenn du das meinst... Denn der ist ja nicht standardisiert außer was UPnP angeht.

Moin!

theChaoS hat folgendes geschrieben :

Was den Server anbelangt: Nein, deswegen habe ich ja UDP gewählt ^^

Bei den Fragen meiner Vorredner geht es auch nicht primär darum, den Server als Dienstleister für die Datenübermittlung zu nutzen, sondern zur Adressvermittlung.

theChaoS hat folgendes geschrieben :

Mein Hauptproblem ist nach wie vor das Port forwading in einen Netzwerk das Dynamische IP Benutzt. Und das ganze sollte dann automatisch (d.H. vom Programm) werden können.

Um es kurz zu machen: vergiss es, dafür gibt es keine wasserdichte Lösung. Grundproblem: NAT-Router ermöglichen nur ausgehenden UDP-Paketen einen (idR zeitlich begrenzten) "Rückkanal", was du dauerhaft nur duch ein Portforwarding auf eine (bekannte) IP umgehen kannst.

Wenn du
a) einen NAT-Router im LAN hast, der dynamisch Adressen vergibt,
b) keinen Zugang zum Router (manuell oder UPnP) hast,
dann kannst du überhaupt nur was mit einem "echten" Internet-Server retten, der als Adressvermittlung für UDP-Hole-Punching dient.

Wenn du die Voraussetzungen nicht erfüllen kannst oder keine Ahnung von UDP-Hole-Punching (und einen dazugehörigen INet-Server) hast, dann kannst du hier aufhören zu suchen.

cu
Narses

Ja wen das Port Forwading Pflicht ist dan bin ich wohl daran gescheitert ^^
schade eigenlich
naja fieleicht wird irgenwan mal ne einfachere art der Kommunikation erfunden ^^
THX an alle fürs Helfen

---Moderiert von Narses: Beiträge zusammengefasst---

P.S. was den Adress Server anbelangt DAS Problem kann ich umgehn ^^.
Da ich kein "normales" DSL hab bekomme ich seit schon 1-3 Monaten keine neue Internet IP zugewisen (sollte net so sein is aber so ^^)

Moin!

theChaoS hat folgendes geschrieben :

Ja wen das Port Forwading Pflicht ist dan bin ich wohl daran gescheitert

Ein Portforwarding ist nicht zwangsweise "Pflicht", lediglich dann, wenn du mit unerwartet eintreffenden Datenpaketen rechnen musst.

Mal ein Beispiel: Du hast ein LAN und einen NAT-Router im Betrieb, dein Freund auch. Nehmen wir mal an, ihr tauscht telefonisch die öffentlichen IP-Adressen eurer Router aus und vereinbart Port 5000. Jetzt sendest du Pakete an <Freund-Router>:5000, er sendet zeitgleich Pakete an <Dein-Router>:5000 - solange, bis ihr beide die Pakete empfangt oder ein Timeout eintritt. Was passiert: Dein Router leitet das UDP-Paket weiter und richtet einen (möglicherweise temporären) "Rückkanal" in deinem Router ein, dass UDP-Pakete an Port 5000 zu deinem Rechner weitergeleitet werden sollen. Das gleiche umgekehrt bei deinem Freund. So gelangen die jeweils vom Anderen gesendeten Pakete dann doch durch den Router. Allerdings: das klappt nicht immer (hängt vom OS des Routers ab) und setzt voraus, dass ihr die IP-Adressen und einen Port ausgehandelt habt (deshalb der INet-Server, dafür ist der dann nämlich zuständig). Das war die Kurzfassung von UDP-Hole-Punching.

Was natürlich auch geht: du kannst auf UDP-Unicasts (üblicherweise innerhalb eines bestimmten Zeitfensters) auch über NAT-Router hinweg antworten, hier ist dann nur beim Sender die IP des "Servers" notwendig und ggfs. ein Portforwarding im "Server-Netz" (sonst würde z.B. eine DNS-Anfrage in einem NAT-Router-Lan ja auch nicht funktionieren).

Was generell nicht geht: UDP-Broadcasts über NAT-Router hinweg (filtert der Router) oder im Internet (filtert der Provider). Wenn das Ziel der ganzen Übung also mal wieder ein "(Internet-)Chat-ohne-IP-des-Servers" werden soll, dann vergiss auch das gleich wieder.

theChaoS hat folgendes geschrieben :

naja fieleicht wird irgenwan mal ne einfachere art der Kommunikation erfunden

Die ist schon erfunden und heißt IPv6. Bis das allerdings produktiv zu haben sein wird, werden wohl noch ein paar Tage ins Land gehen...

theChaoS hat folgendes geschrieben :

was den Adress Server anbelangt DAS Problem kann ich umgehn ^^. Da ich kein "normales" DSL hab bekomme ich seit schon 1-3 Monaten keine neue Internet IP zugewisen

Wir reden hier nicht vom DNS, sondern davon, an unbekannte Peer-IPs zu kommen, oder?

cu
Narses