nicht angemeldet
Spiel zu zweit spielbar
Hi, ich habe eine frage.
Ich wuerde gerne auf meine webseite ein spiel anbieten das zwei leute in echtzeit spielen koennen. Als erstes dachte ich an etwas leichtes wie tic tac to. Programmieren tu ich das mit perl und cgi.
Das problem ist ich weiss nicht wie ich bei solchen spielen vorgehen muss. Muss ich dafür einen server programmieren?
Wie macht man normaler weise soetwas?
Danke mfg
-
Hi, ich habe eine frage.
Ich wuerde gerne auf meine webseite ein spiel anbieten das zwei leute in echtzeit spielen koennen.
Wie macht man normaler weise soetwas?Stichwort AJAX. Oder auch java (etwas komplizierter, aber effektiver)
-
Moin!
Hi, ich habe eine frage.
Ich wuerde gerne auf meine webseite ein spiel anbieten das zwei leute in echtzeit spielen koennen.
Wie macht man normaler weise soetwas?Stichwort AJAX.
Also, was AJAX da jetzt allein tun soll, erschließt sich mir nicht. Insbesondere nicht, wenn du es in einen Zusammenhang setzt mit...
Oder auch java (etwas komplizierter, aber effektiver)
...Java. Beides funktioniert im Browser nicht, wenn kein Server die Kommunikation herstellt zwischen den Spielern.
- Sven Rautenberg
-
Moin!
Hi, ich habe eine frage.
Ich wuerde gerne auf meine webseite ein spiel anbieten das zwei leute in echtzeit spielen koennen.
Wie macht man normaler weise soetwas?Stichwort AJAX.
Also, was AJAX da jetzt allein tun soll, erschließt sich mir nicht.
Mir wiederum erschließt sich nicht, wie du darauf kommst, dass AJAX etwas alleine tun sollte.
Oder auch java (etwas komplizierter, aber effektiver)
...Java. Beides funktioniert im Browser nicht, wenn kein Server die Kommunikation herstellt zwischen den Spielern.
Bei AJAX natürlich nicht. Doch da der OP schrieb "Programmieren tu ich das mit perl und cgi." ging ich davon aus, dass dies serverseitig eingesetzt wird - und somit ein selbiger zur Verfügung steht.
Übrigens: ich kenne mich nicht so gut mit Java aus, aber mit Java sollte sogar ein Spielen ohne übermittelnden Server möglich sein, sofern die IP des anderen Spielers bekannt ist. Ggf. muss das Java-Script ohne die typischen Applet-Beschränkungen ausgeführt werden.
-
Guten Tag,
Übrigens: ich kenne mich nicht so gut mit Java aus, aber mit Java sollte »» sogar ein Spielen ohne übermittelnden Server möglich sein, sofern die IP »» des anderen Spielers bekannt ist. Ggf. muss das Java-Script ohne die
typischen Applet-Beschränkungen ausgeführt werden.Sehr richtig, ein Server ist nicht zwingend nötig. Das sollte jedem, der ein wenig Verstand hat, klar sein.
-
Hi!
Übrigens: ich kenne mich nicht so gut mit Java aus, aber mit Java sollte sogar ein Spielen ohne übermittelnden Server möglich sein, sofern die IP des anderen Spielers bekannt ist. Ggf. muss das Java-Script ohne die typischen Applet-Beschränkungen ausgeführt werden.
Außerdem musst der empfangende Spieler ein Loch in seine Router-Firewall bohren und konfigurieren, dass die auf der öffentlichen IP-Adresse ankommenden Pakete auf die interne IP-Adresse weitergeleitet werden, gegebenenfalls mit noch einem Loch in der Firewall des Rechners. Oder aber, du wartest bis IPv6 sich überall breit gemacht hat, dann musst du nur die Firewall und keine NAT-Problematik beachten. Du brauchst dann keinen zentralen Server, hast dann aber ein neues Problem: Wie leitet man die Mitspielwilligen an, diese Konfigurationen vorzunehmen?
Lo!
-
Hi!
Übrigens: ich kenne mich nicht so gut mit Java aus, aber mit Java sollte sogar ein Spielen ohne übermittelnden Server möglich sein, sofern die IP des anderen Spielers bekannt ist. Ggf. muss das Java-Script ohne die typischen Applet-Beschränkungen ausgeführt werden.
Außerdem musst der empfangende Spieler ein Loch in seine Router-Firewall bohren und konfigurieren,
Muss nicht zwingend. Es reicht die gemeinsame Information über einen bestimmten Zeitpunkt. Wenn dann Client1 eine Anfrage schickt (die Client2 durch die Firewall nicht bekommt), Client2 (jedoch trotzdem) darauf antwortet, dann akzeptiert doch auch die Firewall von Client1 die ankommenden Pakete oder?
Gut gut, es ist nicht alltagstauglich. Aber das Konfigurieren der Firewall ist doch eine Möglichkeit. Wird von den meisten Usern ja auch fürs Filesharing oder Messengerdienste gemacht.
Wie leitet man die Mitspielwilligen an, diese Konfigurationen vorzunehmen?
Ich stelle eine Anleitung ins Netz? (Zur Not lade ich sie bei Rapidshare hoch)
-
Hi!
Außerdem musst der empfangende Spieler ein Loch in seine Router-Firewall bohren und konfigurieren,
Muss nicht zwingend. Es reicht die gemeinsame Information über einen bestimmten Zeitpunkt. Wenn dann Client1 eine Anfrage schickt (die Client2 durch die Firewall nicht bekommt), Client2 (jedoch trotzdem) darauf antwortet, dann akzeptiert doch auch die Firewall von Client1 die ankommenden Pakete oder?Das geht vielleicht mit UDP. Bei TCP würde ich als Firewall nicht den Rückweg öffnen, wenn wegen der anderen Firewall keine Verbindung zustande kommt.
Aber warum willst du nun unbedingt ohne Server kommunizieren, wenn doch sowieso einer vorhanden ist, um das Spiel überhaupt erst einmal anzubieten?
Lo!
-
Hi!
Außerdem musst der empfangende Spieler ein Loch in seine Router-Firewall bohren und konfigurieren,
Muss nicht zwingend. Es reicht die gemeinsame Information über einen bestimmten Zeitpunkt. Wenn dann Client1 eine Anfrage schickt (die Client2 durch die Firewall nicht bekommt), Client2 (jedoch trotzdem) darauf antwortet, dann akzeptiert doch auch die Firewall von Client1 die ankommenden Pakete oder?Das geht vielleicht mit UDP. Bei TCP würde ich als Firewall nicht den Rückweg öffnen, wenn wegen der anderen Firewall keine Verbindung zustande kommt.
Kommt doch zustande (wenn auch künstlich erzeugt).
A schickt Nachricht an B. B empfängt die Nachricht nicht, kennt aber Inhalt und IP der Nachricht (das ist die Voraussetzung). B antwortet nun an A, wie B es auch automatisch tun würde, wenn die Firewall die Pakete nicht abgefangen hätte. As Firewall erkennt nun: aha, Antwort geschickt, Antwort bekommen, Verbindung steht, Verbindung erlaubt - weil von mir selbst ausgehend. Das ganze dann nochmal vertauscht und fertig.
Aber warum willst du nun unbedingt ohne Server kommunizieren, wenn doch sowieso einer vorhanden ist, um das Spiel überhaupt erst einmal anzubieten?
Tja ich weiß auch nicht. Mir war bis eben gerade gar nicht bewusst, dass ich das wollte. Ist aber auch relativ egal, denn das oben Beschriebene ist natürlich rein theoretisch und hat mit Praxis nichts zu tun.
-
Hi!
Das geht vielleicht mit UDP. Bei TCP würde ich als Firewall nicht den Rückweg öffnen, wenn wegen der anderen Firewall keine Verbindung zustande kommt.
Kommt doch zustande (wenn auch künstlich erzeugt).
A schickt Nachricht an B. B empfängt die Nachricht nicht, kennt aber Inhalt und IP der Nachricht (das ist die Voraussetzung). B antwortet nun an A, wie B es auch automatisch tun würde, wenn die Firewall die Pakete nicht abgefangen hätte. As Firewall erkennt nun: aha, Antwort geschickt, Antwort bekommen, Verbindung steht, Verbindung erlaubt - weil von mir selbst ausgehend. Das ganze dann nochmal vertauscht und fertig.Wie gesagt, wenn du das Ganze mit UDP machst, also reinweg nur Datenpakete sendest, dann kannst du so etwas aufziehen. Aber das verbindungsorientierte TCP hat noch ein paar mehr Paketarten auf Lager. Da scheitert die Verbindung schon daran, dass keine Bestätigung auf das die Verbindung eröffnende SYN-Paket zurückkommt, also dasjenige, das eine Verbindung initiiert. B sendet nicht von sich aus aus heiterem Himmel eine Bestätigung auf das SYN-Paket, also SYN+ACK. Zudem weiß B nicht, auf welchem Port geantwortet werden soll und welche Sequenznummer A verwendet hat. Wenn dann noch die Firewall nicht stillschweigend das SYS-Paket verschluckt, sondern mit einem Port-geschlossen-Paket (TCP-RST) antwortet, dann wird sich A leise weinend zurückziehen und Bs gefakte Antworten gar nicht zur Kenntnis nehmen - abgesehen davon, dass B sowieso aufgrund der Sequenznummernunkenntnis nicht korrekt antworten kann.
Lo!
-
Wie gesagt, wenn du das Ganze mit UDP machst, also reinweg nur Datenpakete sendest, dann kannst du so etwas aufziehen. Aber das verbindungsorientierte TCP hat noch ein paar mehr Paketarten auf Lager. Da scheitert die Verbindung schon daran, dass keine Bestätigung auf das die Verbindung eröffnende SYN-Paket zurückkommt,
Ich kann das ACK doch fälschen, indem ich es verschicke ohne das SYN bekommen zu haben oder nicht? (hab ich doch eben beschrieben) Man muss natürlich wissen, _wann_ das ACK versendet wurde.
B sendet nicht von sich aus aus heiterem Himmel eine Bestätigung auf das SYN-Paket, also SYN+ACK.
Doch tut B. Was hindert ihn theoretisch daran?
Zudem weiß B nicht, auf welchem Port geantwortet werden soll und welche Sequenznummer A verwendet hat.
Gut, dass muss dann natürlich alles im Vorhinein ausgetauscht werden.
Wenn dann noch die Firewall nicht stillschweigend das SYS-Paket verschluckt, sondern mit einem Port-geschlossen-Paket (TCP-RST) antwortet,
Ja, das könnte ein Problem werden ;)
-
Hi!
Aber das verbindungsorientierte TCP hat noch ein paar mehr Paketarten auf Lager. Da scheitert die Verbindung schon daran, dass keine Bestätigung auf das die Verbindung eröffnende SYN-Paket zurückkommt,
Ich kann das ACK doch fälschen, indem ich es verschicke ohne das SYN bekommen zu haben oder nicht? (hab ich doch eben beschrieben) Man muss natürlich wissen, _wann_ das ACK versendet wurde.Nein, du weißt die Sequenznummer nicht, auf die du antworten musst.
B sendet nicht von sich aus aus heiterem Himmel eine Bestätigung auf das SYN-Paket, also SYN+ACK.
Doch tut B. Was hindert ihn theoretisch daran?Der vorhandene TCP/IP-Stack. Du könntest natürlich versuchen, den zu umgehen, aber ob da Java mitmacht?
Zudem weiß B nicht, auf welchem Port geantwortet werden soll und welche Sequenznummer A verwendet hat.
Gut, dass muss dann natürlich alles im Vorhinein ausgetauscht werden.Und wie? So ohne Server (wolltest du ja ausgeschlossen haben) und Möglichkeit der direkten Kommunikation? UDP zur Kommunikationsaufnahme? Dann kann man gleiche UDPen.
Lo!
-
Hi!
Aber das verbindungsorientierte TCP hat noch ein paar mehr Paketarten auf Lager. Da scheitert die Verbindung schon daran, dass keine Bestätigung auf das die Verbindung eröffnende SYN-Paket zurückkommt,
Ich kann das ACK doch fälschen, indem ich es verschicke ohne das SYN bekommen zu haben oder nicht? (hab ich doch eben beschrieben) Man muss natürlich wissen, _wann_ das ACK versendet wurde.Nein, du weißt die Sequenznummer nicht, auf die du antworten musst.
Kann A nicht die Sequenznummer, die er selbst abgeschickt hat, herausfinden? Ich wüsste nicht, wie dies verhindert werden sollte, wenn er bis auf die Firewall kompletten Zugriff auf seinen Rechner hat. Er teilt diese dann auf einem anderen Wege B mit und die Sache läuft. (klar, am Anfang _muss_ eine andere Übermittlung funktionieren)
B sendet nicht von sich aus aus heiterem Himmel eine Bestätigung auf das SYN-Paket, also SYN+ACK.
Doch tut B. Was hindert ihn theoretisch daran?Der vorhandene TCP/IP-Stack. Du könntest natürlich versuchen, den zu umgehen, aber ob da Java mitmacht?
Zudem weiß B nicht, auf welchem Port geantwortet werden soll und welche Sequenznummer A verwendet hat.
Gut, dass muss dann natürlich alles im Vorhinein ausgetauscht werden.Und wie? So ohne Server (wolltest du ja ausgeschlossen haben)
Nur ganz kurz anfänglich. _Irgendwie_ müssen sich die Teilnehmer ja bekannt sein, man kann schließlich schlecht alleine spielen. ;)
-
Hi!
Nein, du weißt die Sequenznummer nicht, auf die du antworten musst.
Kann A nicht die Sequenznummer, die er selbst abgeschickt hat, herausfinden? Ich wüsste nicht, wie dies verhindert werden sollte, wenn er bis auf die Firewall kompletten Zugriff auf seinen Rechner hat. Er teilt diese dann auf einem anderen Wege B mit und die Sache läuft. (klar, am Anfang _muss_ eine andere Übermittlung funktionieren)Postkarten wären eine Idee. Egal. Wenn es keinen triftigen Grund gibt, den Server in der weiteren Kommunikation da rauszuhalten, wäre es nicht mein bevorzugter Weg, mit einem Haufen Mehraufwand erstmal am TCP/IP vorbei etwas zu implementieren. Wenn überhaupt, dann etwas UDP-basierendes.
Lo!
-
Hi!
Nein, du weißt die Sequenznummer nicht, auf die du antworten musst.
Kann A nicht die Sequenznummer, die er selbst abgeschickt hat, herausfinden? Ich wüsste nicht, wie dies verhindert werden sollte, wenn er bis auf die Firewall kompletten Zugriff auf seinen Rechner hat. Er teilt diese dann auf einem anderen Wege B mit und die Sache läuft. (klar, am Anfang _muss_ eine andere Übermittlung funktionieren)Postkarten wären eine Idee. Egal. Wenn es keinen triftigen Grund gibt, den Server in der weiteren Kommunikation da rauszuhalten, wäre es nicht mein bevorzugter Weg, mit einem Haufen Mehraufwand erstmal am TCP/IP vorbei etwas zu implementieren. Wenn überhaupt, dann etwas UDP-basierendes.
Meiner auch nicht. ;)
Wie genau unterscheidet sich denn UDP grundsätzlich von IP/TCP? (ich hab keine Lust das jetzt zu recherchieren ._.)-
Hi!
Wie genau unterscheidet sich denn UDP grundsätzlich von IP/TCP? (ich hab keine Lust das jetzt zu recherchieren ._.)
Bei TCP wird eine Verbindung aufgebaut und am Ende wieder abgebaut. Das heißt, es werden ein paar Pakete zur Steuerung der Verbindung ausgetauscht. Die Datenpakete werden durchnummeriert, so dass der Empfänger Reihenfolge und Vollständigkeit prüfen kann. Für TCP weiß eine Firewall, was alles zu einer bestimmten bidirektionalen Verbindung gehört und wann die endet. Bei UDP werden einfach nur Datenpakete geschickt, ohne weitere Kontrolle. Die muss, wenn benötigt, in einer höheren Schicht erfolgen. Da kein Verbindungsstatus gepflegt wird, weiß eine Firewall nichts weiter darüber, als dass da mal jemand ein Paket von A nach B gesendet hat. Sie lässt dann auch Pakete in der Gegenrichtung durch (wenn sie so konfiguriert ist), kann aber nicht genau sagen, wann sie damit aufhören kann. Sie kann da nur genauso schätzen wie eine Website, die "X Besucher sind online" schwindelt.
Lo!
-
-
-
-
-
-
-
-
-
-
-
-
-