socket management, prozesse intelligent verwalten...
-
Hi,
Ich habe vor einen Server für ein Browsergame in C/C++ zu schreiben!
Es steht noch nicht sehr viel fest, aber ich beschäftige mich seit tagen mit sockets, da ich diese ja für den webserver benötige. ( C bzw. C++ behersche ich schon ziemlich gut.)
Das ganze soll später so aussehen:
(Ich denke mir das jetzt nur so, habe nicht wirklich ahnung ob das so funktioniert oder nicht zu ressourcenfressend ist.)Man soll einen prozess starten,
dieser prozess startet 2 childprozesse:
1. webserver (handelt die sockets)
--> startet für jeden client einen weiteren childprozess (im webserver child) und bearbeitet dort alles (informationen aus db auslesen, html generieren, in db schreiben und alles was sonst noch anfällt...)2. berechnungsprozess
--> berechnet alle x minuten (bsp: 5-60min) alles was so anfällt. z.B. gebäude wurde feriggestellt, flotte kommt an->kampf berechnen usw...und nun meine frage:
Ist das so sinnvoll?? Kann man das Intelligenter lösen, wenn ja wie??
und worauf muss ich achten?vielen dank
erazer
-
es wäre echt nett wenn mir mal einer helfen könnte!
Ich möchte auch nur ein paar komentare / vorschläge dazu.
danke
-
Dieser Thread wurde von Moderator/in Marc++us aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Hem, also wenn ich es richtig sehe, willst du einen WebServer implementieren?
Im Prinzip mußt du halt einfach mit Threads arbeiten, die die Prozesse repräsentieren. Wichtiger ist doch, das du dein Protokoll hinbekommst. Die Prozesse zu verwalten ist eher eine simple Geschichte.
Aber um ganz ehrlich zu sein, verstehe ich nicht wirklich warum du einen eigenen WebServer implementieren willst? Wäre es da nicht schlauer und vorallem zeitsparender, wenn du einen fertigen Server nimmst? Z.B. den Apache über CGI bzw. FastCGI. MS hat auch ihren ATL Server den du in C++ programmieren kannst. Das VisualC++2003 Standard hat die nötigen Tools und Libs schon drin.
Auf Codeproject gibts eine Einführung anhand eines Beispiels: http://www.codeproject.com/atl/tipoftheday.asp
-
danke erstmal für deinen tip!
ich möchte das ganze unter gcc für linux programmieren und da bringen mir die libs des VC++ wohl nix.
Der Server soll sehr viele Anfragen bearbeiten können, d.h. in Stosszeiten können schonmal 5000clients / sekunde zustande kommen.
Ich denke mal der Webserver wird wohl das geringste Problem werden.
Ich habe auch zeit, da ich nicht unter Termindruck stehe. (hobbyprojekt)Ich möchte auch nicht direkt den webserver schreiben, sondern werde mich erstmal paar Wochen mit Sockets beschäftigen und mich langsam hocharbeiten. ( C/C++ behersche ich)
Edit: Ich benutze C++ aus Performancegründen.
-
CGIs gibt es auch unter Linux
Das nimmt dir einiges an Arbeit ab. Bis du einen stabilen und sicheren Webserver implementiert hast, bist du mit einem CGI schon längst fertig.
-
mit cgi meinst du warscheinlich perl oder?
ich habe auch schon daran gedacht es in php zu schreiben. Ist ja auch ein modul für den apache!
Die geschwindigkeitsvorteile und möglichkeiten sind aber in C nicht von der hand zu weisen.
Ist ein Webserver wirklich so ein Problem?
auf Port lauschen,
Verbindung annehmen und und dem Client einen eigenen Prozess zuweisen,
dort dann die Seite erstellen und an den Client senden,
Verbindung schließen,
Prozess für den Client beenden.die Ausgaben sollen ja auch nicht aus Dateien geholt werden sondern direkt im C/C++ Code sein.
Ich brauche eigentlich nur ne verbindung annehmen, request auswerten, einen string an den client senden und die verbinding wieder schließen.
Kann man da wirklich soviel falsch machen??
-
Hi,
CGI hat nix mit Perl zu tun, sondern CGI (common gateway interface) ist, wie der Name sagt, eine Schnittstelle. Der Webserver kommunziert quasi mit einem anderen Programm, ob das nun in Perl, Assembler, C oder C++ geschrieben wird ist völlig Hupe.
-
Noch als Hinweis: CGI wird mit Perl nur deshalb oft in Verbindung gebracht, weil CGIs häufig mit Perl realisiert werden. Ist aber kein Zwang.
auf Port lauschen,
Verbindung annehmen und und dem Client einen eigenen Prozess zuweisen,
dort dann die Seite erstellen und an den Client senden,
Verbindung schließen,
Prozess für den Client beenden.Ähem, trivial ist es mit Sicherheit nicht. Aber der Aufwand ist definitiv größer, als einen renommierten Webserver zu benutzen und auf dessen Möglichkeiten aufzubauen.
-
erazer schrieb:
mit cgi meinst du warscheinlich perl oder?
ich habe auch schon daran gedacht es in php zu schreiben. Ist ja auch ein modul für den apache!
Die geschwindigkeitsvorteile und möglichkeiten sind aber in C nicht von der hand zu weisen.
Mein Posting war auf C++ bezogen, nix Perl oder so. CGI heißt einfach, das der Apache deine in C oder C++ compilierte Datei aufruft und dieser dann Parameter mit übergibt und du dann deinen Kram erledigst, normalerweise dem User eine neue HTML-Seite zurück schickst. FastCGI heißt, das der Apache die EXE nur einmalig aufruft und dein Programm nicht mehr aussteigt sondern in einer Schleife läuft. D.h. es ist etwas schneller, weil deine EXE nicht immer und immer wieder neu aufgerufen werden muß.
Da es den Apache mit CGI sowohl unter Windows als auch Linux gibt, wäre es also eine Lösung für dich.
-
ich hab mal gegooglet und habe folgendes gefunden:
http://www.webthing.com/cgiplusplus/
habt ihr so etwas gemeint?wie sieht es mit der geschwindigkeit von c++ programmen aus, die als cgi ausgeführt werden? hab ich dann noch die gleiche geschwindigkeit als wenn ich es als hintergrundprozess laufen habe?
bzw.
Kann ein apache genausoschnell die verbindungen annehmen und das cgi laden und ausführen, als wenn das alles ein c++ programm macht?es geht mir auch darum viele clientanfragen gleichzeitig zu bearbeiten. d.h. 1000-5000 user pro sekunde wenn es hart auf hart kommt...
ich verstehe schon was ihr meint und sehe es auch 100%ig ein, nur ich versuche halt die optimale lösung zu finden!
EDIT:
Danke Artchi für die antwort auf der vorherigen seite!
wenn ich das richtig verstanden habe müsste also FastCGI etwa genauso schnell sein wie ein reines c++ programm.