nicht angemeldet
REALTIME Schachserver
Hallo zusammen,
ich habe ein Schachscript in PHP. Doch leider ist das in PHP geschrieben und somit sind keine Realtime-Spiele möglich, da man die Seite immer auffrischen muss um die aktuelle Stellung zu sehen. Es arbeitet zwar mit refresh, jedoch ist dies natürlich von realtime weit entfernt.
Frage: Welcher Programmiersprache sollte ich mich bedienen, wenn ich einen realtime-Schachserver programmieren möchte ?
Webspace habe ich einen Server (linux) mit fester IP...
Gruss BULI
-
Moin!
Frage: Welcher Programmiersprache sollte ich mich bedienen, wenn ich einen realtime-Schachserver programmieren möchte ?
Um den Server mußt du dich gar nicht kümmern - der Client ist dein Problem. Und das Kommunikationsprotokoll HTTP.
Das ist nämlich darauf ausgelegt, dass ein Client ganz nach belieben anfragt, und der Server dann die aktuelle Situation mitteilt. Es ist aber nicht darauf angelegt, dass der Server den Client informiert, wenn sich was ändert.
Aus dem gleichen Grund sind HTTP-Chats ebenso unmöglich. Sie sind zwar realisierbar, aber sie sind Scheiße, weil eben nicht sofort reagiert wird, sondern immer nur mit Zeitverzögerung durch das nächste Reload.
Mit anderen Worten: Schreibe dir einen eigenen Client. Und weil der mit HTTP nicht wirklich besser wäre, als dein Browser: Schreibe dir auch einen passenden Server und erfinde ein Kommunikationsprotokoll für beide.
Die dafür verwendbare Sprache ist im Prinzip absolut frei wählbar, sofern du diese Wahl nicht durch gewisse Einschränkungen begrenzt. Beispielsweise könntest du fordern, dass der Client überall laufen soll. Daraus ergibt sich, dass er beispielsweise als Applet in Java geschrieben wird. Oder als eigenständige Java-Applikation. Was aber dummerweise voraussetzt, dass Java auf dem Rechner auch installiert ist. Alternativ geht dann natürlich C, C++ o.ä., wobei die Systemunabhängigkeit dabei natürlich verloren geht.
Der Server läßt sich auf die gleichen Überlegungen zurückführen. Systemunabhängigkeit wäre hier nur zu fordern, wenn du den Server universell einsetzbar haben willst (um ihn beispielsweise an andere weiterzugeben), aber auch mit PHP auf der Kommandozeile ließe sich so ein Server grundsätzlich realisieren.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)-
Moin!
Weil mir die besten Ideen immer erst eine Sekunde NACH dem Abschicken kommen: Du kannst natürlich auch bestehende Infrastrukturen und Protokolle zu deinen Gunsten nutzen.
IRC beispielsweise ist eigentlich eine Echtzeit-Chatsoftware. Server gibts dafür mehr als genug, und Client-Bibliotheken für diversteste Programmiersprachen wohl auch.
Aber es ist ja nicht gesagt, dass man damit nur allgemeine Chats betreiben darf. Genausogut kann ja ein Client als Textnachricht einen Schachzug in den Chatraum tippern - bzw. ließe sich eine einzelne Partie wahrscheinlich ganz prima als IRC-Privatgespräch realisieren, während du dann zusätzlich noch den Vorteil hättest, einen allgemeinen Treffpunkt-Chat zum Verabreden und Starten der Partien mit dazuzukriegen.
Die Clients müßten natürlich eine Plausibilitätsprüfung der Schachzug-Chattexte durchführen. Wäre vielleicht sogar sinnvoll, eine Prüfsumme irgendwo mit einzubauen.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)-
Hallo ihr zwei,
IRC beispielsweise ist eigentlich eine Echtzeit-Chatsoftware. Server gibts dafür mehr als genug, und Client-Bibliotheken für diversteste Programmiersprachen wohl auch.
Sven, bei den Einschränkungen von HTTP gebe ich Dir Recht. Allerdings fände ich es unschön, für die Kommunikation auf IRC zurückzugreifen. Für TCP, die Ebene unter IRC, gibt es genauso Bibiotheken und es ist imho sogar unkomplizierter. So kann man sich sein eigenes Protokoll definieren, ohne sich mit IRC-Channels und -Usern herumschlagen zu müssen. Den Server würde ich, da der Code ja schon in php vorliegt, ggfs. in php belassen (ich weiß leider nicht, ob es für php eine TCP-Bibliothek gibt), oder nach Perl portieren, das ist syntaktisch ähnlich und dort gibt es auf jeden Fall ein leicht zu bedienendes Modul für TCP (Stichwort "IO::Socket"). Für den Client würde ich ein Java-Applet verwenden, das kann man prima in eine Website einbinden (keine lästigen Downloads...), man kann komfortabel eine grafische Oberfläche darstellen und für TCP gibt es sicher auch die passenden Klassen.
Simon
-
Moin!
IRC beispielsweise ist eigentlich eine Echtzeit-Chatsoftware. Server gibts dafür mehr als genug, und Client-Bibliotheken für diversteste Programmiersprachen wohl auch.
Sven, bei den Einschränkungen von HTTP gebe ich Dir Recht. Allerdings fände ich es unschön, für die Kommunikation auf IRC zurückzugreifen. Für TCP, die Ebene unter IRC, gibt es genauso Bibiotheken und es ist imho sogar unkomplizierter. So kann man sich sein eigenes Protokoll definieren, ohne sich mit IRC-Channels und -Usern herumschlagen zu müssen.
Du hast natürlich Recht, dass IRC nicht unbedingt einfacher ist. Bei TCP baut man eine Verbindung auf, schreibst und liest ein wenig über den Socket, und irgendwann macht man die Verbindung wieder zu.
Die Sache ist nur: Wenn man diesen Weg gehen will, braucht man dafür einen selbstgeschriebenen Server. Und auch die Möglichkeit, so einen Server dann auf irgendeiner Maschine laufen zu lassen. Das ist keinesfalls ein Feature des handelsüblichen "Webspace", sondern dafür braucht man dann einen eigenen Server, über den man frei verfügen kann. Von den Sicherheitsproblemen, die durch unbekümmerte Selbstprogrammierung von Serversoftware auftreten kann, mal ganz abgesehen.
Da erscheint es mir irgendwie einfacher, wenn man sich nur auf die Clientseite stürzt und IRC implementiert, und sich dann noch einen freundlichen IRC-Server sucht, auf dem man einen eigenen Channel eröffnet und damit testet bzw. diese Infrastruktur dann auch für den endgültigen Einsatz nutzt.
Den Server würde ich, da der Code ja schon in php vorliegt, ggfs. in php belassen (ich weiß leider nicht, ob es für php eine TCP-Bibliothek gibt), oder nach Perl portieren, das ist syntaktisch ähnlich und dort gibt es auf jeden Fall ein leicht zu bedienendes Modul für TCP (Stichwort "IO::Socket").
PHP kann als TCP-Server aktiv werden. Kann sogar forken. Aber ich würde im Zweifel doch lieber ein C-Programm einsetzen, denn PHP und auch Perl ziehen durch ihre Skriptspracheneigenschaft natürlich noch ein erhebliches Maß an Ressourcen und Performance allein für ihre Existenz.
Für den Client würde ich ein Java-Applet verwenden, das kann man prima in eine Website einbinden (keine lästigen Downloads...), man kann komfortabel eine grafische Oberfläche darstellen und für TCP gibt es sicher auch die passenden Klassen.
Was heißt hier "keine lästigen Downloads"? Im Gegenteil: Lästige Downloads bei jedem Seitenaufruf. Nur sieht man die nicht.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)-
Hi Sven,
Die Sache ist nur: Wenn man diesen Weg gehen will, braucht man dafür einen selbstgeschriebenen Server. Und auch die Möglichkeit, so einen Server dann auf irgendeiner Maschine laufen zu lassen. Das ist keinesfalls ein Feature des handelsüblichen "Webspace", sondern dafür braucht man dann einen eigenen Server, über den man frei verfügen kann.
Ahjetztja, Du willst einen bereits bestehenden IRC-Server quasi als Kommunikationszentrale hernehmen. Das ist natürlich ein Vorteil, wenn man nur Webspace mit eingeschränkten Rechten (lies: Zeitlimits für CGI-Skripte) hat.
Was heißt hier "keine lästigen Downloads"? Im Gegenteil: Lästige Downloads bei jedem Seitenaufruf. Nur sieht man die nicht.
In Deinem Fall richtig, wenn der "Schachsever" als CGI-Skript implementiert ist, einen Zug eines Spielers als Eingabe nimmt und seinen Zug ausgibt. Wenn man ein durchgehend laufendes Schachserverprogramm hat (aka TCP-Server), startet das Applet genau einmal, verbindet sich über TCP mit dem Server und beendet sich erst wieder, wenn der Nutzer das Browserfenster schließt oder andere unvorhergesehende Dinge passieren *g*
Übrigens reden wir, glaube ich, aneinander vorbei - Du (und buli?) meinst eine Software, mit der mehrere Menschen untereinander spielen können. Ich denke die ganze Zeit an ein Duell Mensch gegen Schachsoftware auf einem Server. Da besteht natürlich ein gewisser Unterschied...buli, wie solls denn jetzt aussehen? Menschen gegeneinander oder Mensch-Maschine-Duell?
Simon
-
-
-
-