Netzwerkprogrammierung, oh weh...

Hallöchen allesamt. =)
Wie ihr sicherlich schon mitbekommen habt - da ich jeden damit nerve, den ich finden kann - bin ich gerade emsig dabei, ein Kartenspiel zu basteln, und programmiere auch an einer Onlinevariante.
So weit so gut, die Onlinevariante tut auch alles wunderbar - nur leider tut sie das ausschließlich, wenn sich der Unirechner mit meinem verbindet. Ich habe es jetzt auf mehreren anderen Computern versucht, da geht überhaupt nichts.

Zur generellen Funktionsweise:
Auf einem Server habe ich eine Datei mit IP Adressen. Will jetzt Spieler A mit Spieler B spielen, schaut er in der Liste nach, welche IP Spieler B hat, und gibt sie an einen Indy TCP Client weiter, der sich mit Spieler B in Verbindung setzen soll, der einen Indy TCP Server laufen hat.

Ich habe nun nach einigem Herumprobieren herausgefunden, dass die Funktion, die meine eigene IP Adresse ermittelt, die ich anschließend in die Datei auf dem Server schreibe, oftmals eine lokale IP zurückgibt (192.168.x.x).
Wenn sich dann Spieler A mit mir verbinden möchte, bringt ihm diese Adresse also herzlich wenig, da ich ja nicht in seiner Nähe rumhocke, sondern auf einer anderen Kontinentalplatte...

Also habe ich eine PHP-Datei auf meinen Server gelegt, die nichts weiter tut, als die eingehende IP Adresse zurückzugeben. Läuft soweit ganz wunderbar, ich finde somit meine echte externe IP Adresse heraus, und kann die in die Datei auf dem Server eintragen.

Trotzdem kann sich der Indy Client von Spieler A nicht mit mir verbinden, und noch dazu sagt mir mein Indy Server, dass er die IP Adresse nicht registrieren kann. Auch, wenn ich versuche, dem eigenen Indy Server die lokale IP zuzuweisen, und ihn trotzdem von außen mit der externen IP anzusprechen, tut sich nichts.

Kann mir irgendwer einen Tipp geben, wie Netzwerkprogrammierung funktioniert? Ich verzweifel hier langsam, und ich weiß nichtmal, wo ich anfangen soll, mich weiter zu erkundigen, da ich keine Ahnung habe, was genau ich falsch mache. .___.

Wieso schickst du dem Server noch zusätzlich die IP-Adresse vom Client mit?
Für gewöhnlich baut das TCP-Protokoll selbst die Verbindung auf, da die IP-Adresse im Header des Datenpakets steht.
Die Indy Komponente baut ja ein Socket auf, mit der du dann zwischen Netzwerkschnittstelle und Anwendung kommunizieren kannst.
Du sagst dann also im Client nur "Baue mir eine Verbindung nach B auf". Wenn dein Server läuft und ein Socket gestartet wurde, bekommst du dann automatisch die Daten von der Netzwerkschnittstelle und musst nur auf die Daten reagieren. Wenn du Daten vom Server an den Client schicken möchtest, tust du das eben über den Socket und nicht über die IP-Adresse. Die Netzwerkschnittstelle weiß dann schon, wohin er die Daten schicken soll.

Es ist klar, dass Spieler A nicht die benötigte IP-Adresse ermitteln kann, da zwischen Spieler A und B beliebig viele Netzwerke zwischen liegen können und Spieler A nur seine lokale IP-Adresse ermitteln kann.

Öhm, das tue ich gar nicht? Vielleicht habe ich mich doof ausgedrückt...

Wir haben zwei Spieler, die beide wenn sie gerade nichts besseres zu tun haben einen eigenen Server am laufen haben, der darauf wartet, dass sich irgendwer von außen mit ihm verbinden möchte.
Wenn jetzt einer der Spieler auf die Idee kommt, wirklich spielen zu wollen, schauen sie auf dem Webserver nach, welche IP Adresse der andere Server hat, schalten ihren eigenen Server aus und schalten ihren eigenen Client an, und diesem Client wird dann die IP Adresse gegeben, mit der er sich verbinden soll.

Das ganze funktioniert lokal wunderbar, nur wenn ich das im gesamten Internet mache, habe ich das Problem, dass ich entweder eine lokale IP-Adresse an den Client gebe, und der damit nichts anfangen kann, oder, wenn ich eine externe IP-Adresse an den Client gebe, dieser versucht, sich zu verbinden, aber keine Antwort erhält.
Der Server, sobald er gestartet wird, startet übrigens ein Binding, mit festem Port und IP-Adresse, die er abhört; wenn ich ihm die externe IP-Adresse geben will, über den der Client ihn erreichen soll, gibt es haufenweise Fehlermeldungen, dass er diese nicht binden könnte; wenn ich ihm die lokale IP-Adresse gebe, erreicht der Client ihn ebenfalls nicht. .___.
(Oder sollte ich ihn an gar nichts binden? Dann wiederum würde er doch prinzipiell allen Unsinn mithören, der durch das lokale Netzwerk weht - woher wüsste er dann, was an ihn gerichtet ist?)

Die IP-Adresse des Clients ist mir dabei herzlich egal, der muss nur die des Servers kennen und sich mit dem verbinden - nur daran hakt's.



Gäbe es denn, ganz alternativ, eine andere Möglichkeit, wie die beiden miteinander kommunizieren könnten?
Ich will halt nicht viel Traffic auf dem Webserver haben, daher liegen dort nur die IP-Adressen rum, und dann sollen die beiden Programme das unter sich ausmachen, aber vielleicht ist ja der ganze Ansatz Unfug. .___.

Wie gesagt, ich habe von Netzwerkprogrammierung soviel Ahnung wie ein Huhn vom Eierfärben, daher kann es auch sein, dass ich einfach das ganze Konzept falsch verstanden habe. Bitte nicht schlagen. =)

Ich Bullshitte mal ein bisschen rein, also bitte gerne ergänzen oder korrigieren.

Wenn ich dich richtig verstehe will du eine Peer-to-Peer zischen den beiden Spielern herstellen und der externe Spielserver dient nur zum Herstellen der Verbindung. Darauf basierend denke ich, dass man sowohl die lokale als auch die externe IP braucht. Mit der externen werden deine Packete erstmal durch das Netz gejagt.
Fast immer haben wir am anderen Ende aber einen Router o.ä. stehen, der muss dann so eingestellt sein, dass er gewisse Daten direkt an die Rechner weiter leitet. Ich denke Portforwarding ist hier das Stichwort. Aber das habe ich selber auch nicht wirklich verinnerlicht, lediglich ein oder zwei Mal eingestellt bekommen.
Letztlich wird nun aber die lokale IP genutzt um den Endempfänger zu ermitteln. Ab dann kümmert sich dann wieder das System um die Daten.

Wenn du sagst, dass es auf deinem Rechner aber nicht auf anderen System läuft, stellt sich mir die Frage ob dein Netzwerk vielleicht schon darauf hingehend konfiguriert hast. In diesem Sinne könnten weitere Versuche an anderen Örtlichkeiten helfen. Oder weitere Systeme im eigenen Netzwerk.

Ich bin aber auch überzeugt, dass dieser Ansatz "veraltet" ist, in so fern, dass er doch ein bisschen Konfiguration erfordert und es sicher eine einfachere Möglichkeit gibt. Würde mich freuen, wenn jemand da Klarheit verschaffen kann.

Japp, du hast es genau richtig verstanden: Ich brauche nur eine Möglichkeit, wie sich die beiden Programme miteinander unterhalten können. Von mir aus müsste der Webserver überhaupt nicht einbezogen werden, aber ich nutze ihn halt ganz zu Anfang einmal, um die IP des anderen zu finden.

Und ja, genau den nicht-veralteten, standardmäßigen, heutigen Ansatz dafür, den suche ich. Ich will ja gar nicht immer alles unglaublich schrecklich und nonkonform programmieren, ich weiß nur einfach nicht, wie man das standardmäßig macht. =)
Also wenn irgendwer Ideen dazu hat, oder auch einfach nur Schlagwörter (wie das Portforwarding, da werd ich mich mal drüber informieren) bitte gern her damit!

Gerade habe ich auch das Problem, das alles nicht einfach testen zu können - habe ich zwei Rechner im selben Raum vor mir stehen, sind die in so ziemlich 100% der Fälle auch im gleichen lokalen Netzwerk, und alles funktioniert sowieso tadellos. Die Probleme tauchen erst auf, wenn sich zwei weiter entfernte Geräte verbinden wollen, und da kann ich nunmal nicht bei beiden gleichzeitig danebenstehen, Nachrichten abfangen, und schauen, woran es jetzt genau scheitert...

Effektiv wäre mir an einer Lösung gelegen, die ohne zusätzliche Routerkonfiguration auskommt, da viele Menschen eben an ihren Routern nichts konfigurieren dürfen (weil sie im Studentenwohnheim wohnen, über das Uninetz ins Netzwerk gehen, solcherlei Dinge), aber wenn das unmöglich ist, wär mir echt alles erstmal lieber als die derzeitige Notlösung:

Ich hab jetzt nämlich erstmal eine Art Nofallmodus gebastelt, der überall wunderbar funktioniert, aber intern totaler Mist ist. (Die beiden Spieler senden alle Daten über den Webserver und kommunizieren überhaupt nicht direkt - was im Endeffekt auf eine selbstgemacht DDoS-Attacke auf meinen eigenen Webserver hinausläuft, armes kleines Ding...) Daher brauche ich wirklich eine bessere Möglichkeit. ^^

Kann grade keinen langen Text schreiben, aber hast du dich mal über UDP hole punching informiert? Das könnte dir evtl. helfen.

Hey, das schaut knuffig aus. Danke. ^_^

Ich kann dir auch schnell zusammenfassen, wie es funktioniert, wenn du willst. Ist an sich super simpel.

Danke für deine Einführung zum Thema UDP. =)

Nun hat es aber schon wieder das nächste Problem:
Wenn ein Spieler A sich mit Spieler B verbinden möchte, soll Spieler B das durch den Webserver erfahren. Also wäre das einfachste, einfach eine TCP-Verbindung zwischen B und Webserver aufrecht zu haben.
Um das zu machen, habe ich mich jetzt stundenlang durch PHP-Socketprogrammierung gelesen, bis ich endlich so weit war, und meine php-Datei auf den Server packte, um was zu erfahren?
Die php_sockets.dll ist in meiner php.ini nicht eingetragen, den Eintrag kann ich nicht ändern, weil ich für Schreibrechte auf die php.ini einen höheren Tarif bezahlen müsste, dl ist deaktiviert, sodass ich die sockets nicht zur Laufzeit nachladen kann, und exec ist deaktiviert, sodass ich nicht die php-Datei mit anderer php.ini aufrufen kann.

Ich HASSE Webprogrammierung...

Das hat nix mit Webprogrammierung zu tun, sondern damit, dass dich dein Provider über den Tisch zieht.

Zitat:

---

Zitat von Moyaccercchi

Ich HASSE Webprogrammierung...

---

Willkommen im Club :D

Zitat:

---

Zitat von DFYX

Das hat nix mit Webprogrammierung zu tun, sondern damit, dass dich dein Provider über den Tisch zieht.

---

Es gibt viele Provider, die im Basis-Angebot so was nicht inbegriffen haben, da man Sockets und Systemaufrufe nicht unbedingt für eine Webseite benötigt und auch ein Risiko darstellen kann.

Okay, ich glaube, ich habe einen Weg gefunden, mich an der Socket-Sperre vorbeizumogeln. *g*

Spieler B sendet eine Anfrage nach einer php-Seite an den Webserver. Die php-Datei wiederum geht in eine Schleife, und liest aus, ob Spieler A eine Nachricht auf dem Server hinterlassen hat. Sobald A eine Nachricht sendet, wird diese von der php-Datei gefunden, der Inhalt der Nachricht an B weitergeleitet, und das Script beendet.

Somit sendet B nur einen einzigen Request, und nur, wenn sich wirklich eine Nachricht eingefunden hat, wird ein neuer Request gesendet, anstatt dies andauernd tun zu müssen. Ist alles noch viel wackeliger, als mir lieb wäre, aber schonmal besser als nichts...

Zitat:

---

Zitat von Whiz-zarD

Es gibt viele Provider, die im Basis-Angebot so was nicht inbegriffen haben, da man Sockets und Systemaufrufe nicht unbedingt für eine Webseite benötigt und auch ein Risiko darstellen kann.

---

Richtig, aber nachdem ich gehört hab, was Moya für das Angebot zahlt...

Zitat:

---

Zitat von DFYX

Richtig, aber nachdem ich gehört hab, was Moya für das Angebot zahlt...

---

Ist denn das Preis-/Leistungsverhältnis so schlecht, wenn ich 12 € im Jahr zahl, und dafür dann eben ein paar Dinge nicht bekomme (wie eine Möglichkeit, die php.ini zu ändern, gnaaar! ^^)?
Ich kenn mich bei den Angeboten einfach nicht so aus, und wüsste nicht, was für ein Preis da angemessen wär. o.o

Ah, pardon, ich hatte gestern verstanden, dass du 12 Euro im Monat zahlst, nicht im Jahr. Dann ist das natürlich was anderes.

Mau...
Ich verzweifel hier noch mit dem Mist. ^^

Okay, ich nutze jetzt UDP als Übertragungsprotokoll und UDP hole punching, um vom einen Computer auf den anderen durchzukommen. Sollte im Prinzip so laufen.
Aber wieder stehe ich genau an der Stelle, an der ich schon mit TCP stand: im lokalen Netzwerk läuft alles wunderbar, nach einigem hin und her wird eine stabile „Verbindung“ über UDP aufgebaut (ich weiß, dass es da keine richtigen Verbindungen gibt, aber es werden eben ständig Pakete hin und her geschickt) und alles läuft fein.
Nehme ich dasselbe Programm nun, und lass es auf das groooße weite Internet los, passiert gar nichts. Es können so viele holes gepuncht und Pakete gesendet werden, wie man will, auf beiden Computern die das Programm laufen lassen kommt einfach kein einziges UDP-Paket an.
Die IP-Adresse an die die Pakete gesendet werden ist tatsächlich die externe Adresse, zumindest auf meinem Computer habe ich das Programm auch explizit durch die Firewall erlaubt (das heißt, selbst wenn die Firewall auf der anderen Seite bockig ist, sollten die Pakete wenigstens in eine Richtung durchkommen), und ich bin echt mit meinem Latein am Ende.
Gibt es irgendeinen typischen Anfängerfehler, der so trivial ist, dass niemand auf die Idee gekommen sein könnte, mich davor zu warnen, auf ihn hereinzufallen, den ich aber ob meiner totalen Blauäugigkeit übersehen haben könnte?

Sorry für den Doppelpost, aber es haben sich neue Erkenntnisse ergeben. ^^

Wenn ich mein Programm von der Uni aus nutze, und mit irgendwem in Deutschland spiele, läuft der UDP-Modus wunderbar, in beide Richtungen werden fröhlich Pakete versandt, Regenbogen, Ponies, was immer man will - es ist also nicht nur das lokale Netz, in dem das läuft. ^^

Wenn ich mein Programm aber zu Hause starte, habe ich noch immer dasselbe Problem - es kommen keine Pakete an, weder bei mir, noch beim Gegner. Kann es sein, dass bei mir zu Hause ein garstiger Router steht, der einfach nichts durchlässt? (Ich könnte dessen Konfiguration nicht ändern, selbst wenn ich wollte, da er mir nicht gehört, sondern dem ganzen Haus und insbesondere dem Hausbesitzer...)
Also, was kann ich tun, dass meine UDP-Pakete da durchkommen? Und nein, Pakete gehen nichtmal raus durch diese komische Verbindung. Dass sie nicht reingehen ist ja komisch genug, aber nicht rausgehen... ?

Sehr wahrscheinlich, dass es der Router ist, ja. Musst du dir wohl noch ein paar mehr Opfer Tester suchen, um der Sache weiter auf den Grund zu gehen.