Frage zum Port-Fprwarding mit C++
-
Belli schrieb:
Ich hoffe, das ist nicht ernst gemeint ...
Ehm.. warum
(Klar kannst du etwas das "bind()" aufruft als Server bezeichnen, aber den Router kratzt das nicht.)
-
Router? Lass den erst mal weg.
Wenn ich auf einem Rechner keine Software habe, die auf irgendeinem Port lauscht:cooky451 schrieb:
Belli schrieb:
Ja, aber da muss doch ein Server(Socket) lauschen ...?!
Ne, die Clienten vera*schen sich gegenseitig
wie soll ich dann damit Verbindung aufnehmen?
-
cooky451 schrieb:
(Klar kannst du etwas das "bind()" aufruft als Server bezeichnen
Wie würdest Du es denn bezeichnen?
-
Belli schrieb:
Router? Lass den erst mal weg.
Hä? Es ging hier doch um den Router
-
Naja, es ging darum, dass ein Server hinter einem Router nicht ohne Port-Forwarding erreichbar ist. DU wolltest eine Verbindung zwischen zwei Clients OHNE Server herstellen:
cooky451 schrieb:
Belli schrieb:
Ja, aber da muss doch ein Server(Socket) lauschen ...?!
Ne, die Clienten vera*schen sich gegenseitig
um Dir DAS zu vereinfachen - weil ich keine Vorstellung habe, wie das gehen soll - solltest Du DAS ZUNÄCHST erst mal ohne Router machen ...
-
Belli schrieb:
Naja, es ging darum, dass ein Server hinter einem Router nicht ohne Port-Forwarding erreichbar ist.
Ist er doch. Sende ein UDP Paket an eine Adresse und warte auf die Antwort. So kannst du auch ohne im Router irgendetwas freigeben zu müssen eine Verbindung herstellen. Ob man ein Programm das "bind()" aufruft um etwas empfangen zu können jetzt Server nennt, steht auf einem anderen Blatt. Ich würde es nicht so bezeichnen.
-
cooky451 schrieb:
Belli schrieb:
Naja, es ging darum, dass ein Server hinter einem Router nicht ohne Port-Forwarding erreichbar ist.
Ist er doch. Sende ein UDP Paket an eine Adresse und warte auf die Antwort. So kannst du auch ohne im Router irgendetwas freigeben zu müssen eine Verbindung herstellen.
So kann ich auch eine TCP/IP - Verbindung herstellen, WENN ich denn eine Antwort bekomme. Wo aber soll die herkommen, wenn 'die Adresse' hinter einer Firewall sitzt?
-
Belli schrieb:
Wo aber soll die herkommen, wenn 'die Adresse' hinter einer Firewall sitzt?
Die Antwort wird einfach geschickt. Sie ist keine direkte Reaktion auf eine Anfrage, sondern muss natürlich ausgelöst werden. Die Anfrage dient nur dazu, den Router auf eine Antwort einzustellen.
-
Also:
cooky451 schrieb:
Ist er doch. Sende ein UDP Paket an eine Adresse und warte auf die Antwort.
ich sende ein UDP Paket an eine Adresse, und dann
cooky451 schrieb:
Die Antwort wird einfach geschickt. Sie ist keine direkte Reaktion auf eine Anfrage, sondern muss natürlich ausgelöst werden.
das kann doch nur dann funktionieren, wenn das von irgendwem - im Fall von Skype macht das der Skype-Server - gesteuert wird, denn mein Router wird eine 'Antwort' ja nur dann durchlassen, wenn sie von der Adresse kommt, an die ich mein UDP-Paket gesendet habe, und diese Adresse muss erst mal meine IP/Port wissen, und wann der richtige Zeitpunkt gekommen ist, um mir eine 'Antwort' zu senden.
Ich bleibe also dabei: In diesem Fall braucht man erst mal irgendwo einen Server, auf den die Beteiligten connecten können; dieser kümmert sich dann über die bestehenden Verbindungen zu den beiden darum, dass die nötigen Informationen (IP/Port, Zeitpunkt) zur Verfügung stehen.
Hier
http://www.heise.de/security/artikel/Wie-Skype-Co-Firewalls-umgehen-270856.html
ist ganz gut beschrieben, wie Skype es macht.Beachte:
"Eine wichtige Aufgabe beim Gesprächsaufbau mit Skype übernimmt ein Vermittlungsserver, mit dem beide Kommunikationspartner in ständigem Kontakt stehen."Es ist letztendlich keine Lösung, die geeignet ist, dem TE das Port-Forwarding zu ersparen.
-
Belli schrieb:
Ich bleibe also dabei: In diesem Fall braucht man erst mal irgendwo einen Server, auf den die Beteiligten connecten können; dieser kümmert sich dann über die bestehenden Verbindungen zu den beiden darum, dass die nötigen Informationen (IP/Port, Zeitpunkt) zur Verfügung stehen.
Angenommen man möchte ein Spiel übers Netz spielen, aber jemand der eigentlich keine Ahnung von Routern hat, bzw. vielleicht nicht einmal Zugriff auf diesen hat, soll hosten, da sein Rechner am schnellsten ist. Dann wäre das die optimale Lösung und man braucht keinen Server dazwischen.
-
cooky451 schrieb:
Angenommen man möchte ein Spiel übers Netz spielen, aber jemand der eigentlich keine Ahnung von Routern hat, bzw. vielleicht nicht einmal Zugriff auf diesen hat, soll hosten, da sein Rechner am schnellsten ist. Dann wäre das die optimale Lösung und man braucht keinen Server dazwischen.
Dann skizzier doch mal kurz, wie das gehen soll?
Der Host wartet auf Anfragen, auf die er Antworten schickt. Okay.
Da er aber hinter einem Router hängt, bekommt er gar keine Anfragen, was also nun?cooky451 schrieb:
Die Antwort wird einfach geschickt. Sie ist keine direkte Reaktion auf eine Anfrage, sondern muss natürlich ausgelöst werden. Die Anfrage dient nur dazu, den Router auf eine Antwort einzustellen.
An wen wird die Antwort denn einfach geschickt? Woher hat der Host die Adressen, an die die 'Antworten' geschickt werden müssen? Und wodurch werden sie 'ausgelöst'?
-
ICQBoy1: Hey, lass mal zocken!
ICQBoy2: Ok! Meine IP: 123.123.123.123
ICQBoy1: Meine IP: 321.321.321.321
ICQBoy2: Hab geschickt, Port offen.
ICQBoy1: Verbindung steht!
-
cooky451 schrieb:
ICQBoy1:
ICQBoy2:Aha, aber da hast Du gleich zwei Server ...
Die IP's müssen ja nicht nur festgestellt und übermittelt werden, sondern auch noch eingetippt ...Wie gesagt, ohne Server wird das nix. Da ändert auch die Tatsache nichts dran, dass Du nun Server aus Fleisch und Blut einsetzt.
-
Hä? Wenn ich jetzt in meinen Browser eine IP eingebe um auf Google zu kommen, bin ich deshalb doch kein Server
-
Richtig, der Server sitzt ja auch bei Google und wartet auf Anfragen, die er beantwortet. In Deinem Beispiel würdest Du zuerst bei Google anrufen, Deine IP/Port durchgeben, dann Deine Anfrage starten, und Dein Telefonpartner bei Google würde jetzt Deine IP/Port - Daten in seine Software eintippen und so ein 'Antwort'-Paket erzeugen.
Btw.
Wenn ich ein UDP-Paket verschicke, und mein Router also weiß, dass ich auf eine Antwort des von mir adressierten Rechners warte - wie lange würde er eine Antwort akzeptieren? Ich kann mir nicht vorstellen, dass er unbegrenzt lange warten würde, oder doch?
-
Es geht folgendermaßen: beide Clients wissen die IPs des jeweils anderen Router und schicken jetzt (mehr oder weniger gleichzeitig beginnend) fortlaufend UPD-Packete an den anderen Router. Beide Router registrieren jetzt, dass UDP-Packete an einen Server (den andere Router) verschickt werden und erwarten eine Antwort. Und diese kommt ja vom anderen Client. Also bekommen beide Clients eine UDP-Verbindung, obwohl sie beide hinter einem NAT sitzen.
Ich meine dann ist es auch möglich, eien TCP-Verbindung aufzubauen, dazu weiß ich jetzt aber nichts genaueres.
-
Belli schrieb:
Richtig, der Server sitzt ja auch bei Google und wartet auf Anfragen, die er beantwortet. In Deinem Beispiel würdest Du zuerst bei Google anrufen, Deine IP/Port durchgeben, dann Deine Anfrage starten, und Dein Telefonpartner bei Google würde jetzt Deine IP/Port - Daten in seine Software eintippen und so ein 'Antwort'-Paket erzeugen.
Ich meine du kannst auch jeden und alles als Server bezeichnen der auf Informationen wartet, aber das hat doch reichlich wenig mit der Praxis zu tun.
Ich meine dann ist es auch möglich, eien TCP-Verbindung aufzubauen, dazu weiß ich jetzt aber nichts genaueres.
Wär mal eine lustige Idee, dürfte aber recht aufwändig sein. Das erste Problem ist der 3-Way-Handshake. Mit der vorgefertigten connect() Funktion wird ein SYN gesendet und ein SYN/ACK erwartet. Die connect() Funktion der Gegenseite kann aber kein SYN/ACK liefern. Wenn überhaupt, dann braucht man dafür dann RAW Sockets, was halt wesentlich aufwändiger ist. (Und auch da muss man noch die "Sequence number" beachten etc. pp.)
-
cooky451 schrieb:
Belli schrieb:
Richtig, der Server sitzt ja auch bei Google und wartet auf Anfragen, die er beantwortet. In Deinem Beispiel würdest Du zuerst bei Google anrufen, Deine IP/Port durchgeben, dann Deine Anfrage starten, und Dein Telefonpartner bei Google würde jetzt Deine IP/Port - Daten in seine Software eintippen und so ein 'Antwort'-Paket erzeugen.
Ich meine du kannst auch jeden und alles als Server bezeichnen der auf Informationen wartet, aber das hat doch reichlich wenig mit der Praxis zu tun.
Aha ...
soviel ich weiß, ist es aber weit verbreitet, solche Programme, die zum Beispiel Deine Anfrage an google entgegennehmen, Webserver zu nennen.
Im übrigen bezeichne ich nicht alles, was auf Informationen wartet, als Server, sondern alles, was Dienste anbietet, indem es auf Anfragen wartet, die es dann bestimmungsgemäß beantwortet, zB Webserver, Gameserver, etc.Meinem bescheidenen Informationsstand gemäß ist das auch sehr wohl gängige Praxis. Vielleicht sagst Du mal, was Deiner Meinung nach der Unterschied zwischen einem Server und einem Client ist, bzw. was Du unter einem Server verstehst?
-
Belli schrieb:
zB Webserver, Gameserver, etc.
Belli schrieb:
Telefonpartner
Belli schrieb:
Vielleicht sagst Du mal, was Deiner Meinung nach der Unterschied zwischen einem Server und einem Client ist, bzw. was Du unter einem Server verstehst?
Zwei Erklärungen, wenn eine Zutrifft ist das Programm ein Server:
1. Ein Programm das dauerhaft auf eine Anfrage von außen wartet (z.B. listen()), dann eine feste Verbindung herstellt (z.B. accept()). (Webserver)
2. Ein Programm das in irgendeiner Weise die Verwaltung mehrer Clienten übernimmt. (Gameserver)Das artet aber eh in Definitionswischerei (schönes Wort) aus, von mir aus sag halt zu allem was bind() aufruft oder irgendwie auf Informationen wartet Server, das ändert aber nichts daran, dass man so ohne einen Port öffnen zu müssen eine Verbindung bekommt. (Und ohne einen Server mieten zu müssen, der das Ganze verwaltet.)
-
Also kann man abschließend sagen, dass eine solche Verbindung ohne externen Server und ohne Port-Forwarding nicht möglich ist auf TCP-Ebene?