nicht angemeldet
Eigener Webserver (preforked)
0 0 0
0
Eigener Webserver (preforked)
Hallo,
ich hab vor einen eigenen (light) Webserver zu programmieren.
Ich hab vor folgendes über Perl zu machen:
Ein Webserver-Starter, der 10 Worker-Child-Prozesse erstellt und auf einkommende Verbindungen hört (Socket-Listen). Diese Verbindungen sollen (z.B. nach Round-Roubin Prinzip) auf die 10 Worker verteilt werden.
Frage: Wie kann ich das realisieren? - Wie sagt der Webserverhauptprozess seinen Kindern, was sie abarbeiten sollen bzw. für welchen Request sie zuständig sind?
pipes? Unix-Domain-Socket?
... und: ich frage mich, ob das nicht effizienter gelöst werden kann, denn: der ganze Traffic würde bei pipes und sockets trotzdem noch über den Vater-Prozess laufen => dann brauch ich ja gar keine Child's um die Requests abzuarbeiten, wenn der Vater trotzdem noch so viel schuften muss..??
Grüsse,
Maxwell
-
hallo,
ich hab vor einen eigenen (light) Webserver zu programmieren.
Sehr interessant, da würde ich gerne deine Ergebnisse (auch im "prä-alpha-Stadium") haben, um nachzuschauen, wie du das anstellst.
Ich hab vor folgendes über Perl zu machen:
Ups. Meines Wissens (was hier eventuell Lücken aufweist) hat es noch niemand versucht, einen Webserver in Perl zu realisieren. Lösungen in JAVA oder TCL/Tk sind mir bekannt, sonst natürlich allerhand Versuche in C. Aber nicht in Perl.
Ein Webserver-Starter, der 10 Worker-Child-Prozesse erstellt
Moment. Du sprichst von "worker". Das ist eine Vokabel aus dem Umfeld des Apache. Warum willst du nicht gleich den Apache nehmen? Der ist bereits "fertig", und du darfst ja bekanntlich in den Sourcen herumfummeln, soviel du möchtest.
Grüße aus Berlin
Christoph S.
-
Hallo Christoph
ich hab vor einen eigenen (light) Webserver zu programmieren.
Sehr interessant, da würde ich gerne deine Ergebnisse (auch im "prä-alpha-Stadium") haben, um nachzuschauen, wie du das anstellst.Ist halb so wild, wirklich.
use HTTP::Daemon
und schon hast du einen.
Ups. Meines Wissens (was hier eventuell Lücken aufweist) hat es noch niemand versucht, einen Webserver in Perl zu realisieren. Lösungen in JAVA oder TCL/Tk sind mir bekannt, sonst natürlich allerhand Versuche in C. Aber nicht in Perl.
Was hat TCL/Tk damit zu tun?
Klar, Perl ist nicht die erste Sahne für Webserver, geht mir auch mehr um die Umsetzung (wie das eben geht mit den worker-prozessen), als ihn wirklich laufen zu lassen.Moment. Du sprichst von "worker". Das ist eine Vokabel aus dem Umfeld des Apache. Warum willst du nicht gleich den Apache nehmen? Der ist bereits "fertig", und du darfst ja bekanntlich in den Sourcen herumfummeln, soviel du möchtest.
Apache ist schon fertig. Ich will's eben selber können. Sourcen, naja, ist bei Apache ziemlich aufwändig schätze ich ;-)
Und ja, ich hab den Apache sozusagen als Vorbild und will eben diese Client-Server-Worker-Technik selber umsetzen. Nur wie???Grüsse,
Maxwell
-
hallo Maxwell,
use HTTP::Daemon
und schon hast du einen.Ich wäre mir da nicht so sicher. Es könnte sein, daß ich das eine oder andere von Perl verstanden habe. Es gibt zwar ein Beispiel für HTTP::Daemon, das dir gewiß bekannt ist, aber schon das setzt voraus, daß es mit Hilfe eines bereits völlig "fertigen" Webservers (Apache) gestartet wird.
Ups. Meines Wissens (was hier eventuell Lücken aufweist) hat es noch niemand versucht, einen Webserver in Perl zu realisieren. Lösungen in JAVA oder TCL/Tk sind mir bekannt, sonst natürlich allerhand Versuche in C. Aber nicht in Perl.
Was hat TCL/Tk damit zu tun?Nicht viel - aber man kann mit dieser vermutlich zu Unrecht weniger beachteten Sprache durchaus einen vollständigen Webserver schreiben, der dann ohne Zuhilfenahme des Apache auskommt.
Und ja, ich hab den Apache sozusagen als Vorbild und will eben diese Client-Server-Worker-Technik selber umsetzen. Nur wie?
Indem du deinen Apache deinstallierst und dir die Grundlagen für einen "Webserver" zusammensammelst. Was du machen möchtest, reduziert sich auf die Benutzung einer Perl-Funktionalität. Du kannst daran(damit/dabei gewiß einiges lernen, nur wird das vermutlich niemals ein völlig neuer eigener Webserver.
Grüße aus Berlin
Christoph S.
-
Hallo Christoph
Ich wäre mir da nicht so sicher. Es könnte sein, daß ich das eine oder andere von Perl verstanden habe. Es gibt zwar ein Beispiel für HTTP::Daemon, das dir gewiß bekannt ist, aber schon das setzt voraus, daß es mit Hilfe eines bereits völlig "fertigen" Webservers (Apache) gestartet wird.
Nein, das Script kann von der Konsole gestartet werden und läuft prima ohne Webserver. Es ist ein HTTP Daemon, hört also selber auf einkommende Verbindungen am z.B. Port 80 und dann kannst du mit denen machen, was du willst.
Nicht viel - aber man kann mit dieser vermutlich zu Unrecht weniger beachteten Sprache durchaus einen vollständigen Webserver schreiben, der dann ohne Zuhilfenahme des Apache auskommt.
Man kann mit so ziemlich jeder Internetfähigen Script-/Programmiersprache einen Webserver erstellen. Wichtig ist nur, dass sie Sockets unterstützt.
Indem du deinen Apache deinstallierst und dir die Grundlagen für einen "Webserver" zusammensammelst. Was du machen möchtest, reduziert sich auf die Benutzung einer Perl-Funktionalität. Du kannst daran(damit/dabei gewiß einiges lernen, nur wird das vermutlich niemals ein völlig neuer eigener Webserver.
Die Grundlage für Client-Server will ich ja eben bei euch erfragen. Wie man einen Webserver programmiert ist mir schon bekannt und das habe ich auch schon gemacht, np. Nur will ich eben diese Client-Server Umsetzung kennen. Ich will auch keinen eigenen neuen Webserver, sondern nur die Client-Server umsetzung dahinter verstehen. Ob es am Ende ein Webserver oder eine Datenbank wird ist mir sogar auch egal. MySQL arbeitet zum Beispiel etwa analog. Der mysql-server wartet auf Verbindungen im Unix-Domain-Socket und delegiert die Anfragen auf den verbindungs-server. Nur wie läuft die Kommunikation, das ist die einzige Frage, die ich habe.
Grüsse,
Maxwell
-
Man kann mit so ziemlich jeder Internetfähigen Script-/Programmiersprache einen Webserver erstellen. Wichtig ist nur, dass sie Sockets unterstützt.
In Perl IO::Socket. Allerdings bietet Perl keine native Socket-Unterstützung, sondern greift via Socket.pm auf die entsprechenden C-Bibliotheken zu.
Die Grundlage für Client-Server will ich ja eben bei euch erfragen. Wie man einen Webserver programmiert ist mir schon bekannt und das habe ich auch schon gemacht, np. Nur will ich eben diese Client-Server Umsetzung kennen.
Ein Webserver basiert ausschließlich auf dem Client-Server-Prinzip. Wie um alles in der Welt hast du einen Webserver programmiert, wenn dir dieses Prinzip unklar ist?
Nur wie läuft die Kommunikation, das ist die einzige Frage, die ich habe.
Via HTTP, schau dir also die Details dieses Protokolles an. Einen guten Einstieg bietet die wikipedia:
http://de.wikipedia.org/wiki/Hypertext_Transfer_ProtocolAnsonsten schau dir mal an, wie es andere gemacht haben:
http://www.rblasch.org/studies/cs629/pa3/index.htmlSiechfred
--
Ein Selbständiger ist jemand, der bereit ist, 16 Stunden am Tag zu arbeiten, nur um nicht 8 Stunden für einen Anderen arbeiten zu müssen.-
Hallo Siechfred
In Perl IO::Socket. Allerdings bietet Perl keine native Socket-Unterstützung, sondern greift via Socket.pm auf die entsprechenden C-Bibliotheken zu.
I know.
Ein Webserver basiert ausschließlich auf dem Client-Server-Prinzip. Wie um alles in der Welt hast du einen Webserver programmiert, wenn dir dieses Prinzip unklar ist?
Ist mir durchaus bekannt. Du hast mich nicht verstanden, oder ich hab mich undeutlich ausgesprochen. Mir geht es *nicht* um einen Webserver alla:
my $s = IO::Socket::INET(...);
while (my $c = $s->accept()) {
my $p = fork();
if (defined($p)) {
if ($p==0) {
# mach was mit $c
}
}
}Also reines Client-Server-Prinzip, sondern etwas wie:
my $s = IO::Socket::INET(...);
preforking workers
our @workers = ();
for ( my $i=0; $i<10; $i++ ) {
my $p = fork();
if (defined($p)) {
# mach pipe/socket zum worker...
$workers[$i] = $pipe;
}
}sub let_it_handle_by_worker($$) {
my ($client,$worker_id) = @_;
# was steht hier, wie kann ich den worker den request
# per pipe abarbeiten lassen und die Response direkt zum
# client schicken (so dass der Hauptprozess der die
# Verbindungen entgegennimmt nicht arbeiten muss)??????
}while ( my $c = $s->accept() ) {
let_it_handle_by_worker($c, int((rand()*10)) % 10)
}das ist meine Frage. Klar?
Via HTTP, schau dir also die Details dieses Protokolles an. Einen guten Einstieg bietet die wikipedia:
http://de.wikipedia.org/wiki/Hypertext_Transfer_ProtocolJa, ja, kenn ich im Schlaf.
Ansonsten schau dir mal an, wie es andere gemacht haben:
http://www.rblasch.org/studies/cs629/pa3/index.htmlNice and easy.
Grüsse,
Maxwell
-
Du hast mich nicht verstanden, oder ich hab mich undeutlich ausgesprochen.
Letzteres :) Und leider kann ich dir nicht wirklich weiterhelfen, meine aber, dass du mit Threads vielleicht besser bedient bist als mit Prozessen. Aber eventuell könnte dich dieser Artikel interessieren. Daneben könnte ein Blick auf Proc::Fork nicht schaden, da gibt's ein paar nette Beispiele. Für umfassendere Perl-Hilfe könntest du auch im Forum der Perl-Community nachfragen.
Siechfred
--
Ein Selbständiger ist jemand, der bereit ist, 16 Stunden am Tag zu arbeiten, nur um nicht 8 Stunden für einen Anderen arbeiten zu müssen.
-
-
-
-
-
-
Hallo!
Ups. Meines Wissens (was hier eventuell Lücken aufweist) hat es noch niemand versucht, einen Webserver in Perl zu realisieren. Lösungen in JAVA oder TCL/Tk sind mir bekannt, sonst natürlich allerhand Versuche in C. Aber nicht in Perl.
Ich hab mal in irgendeinem uralten Buch eine Komplettumsetzung eines Webservers in perl gefunden. Allerdings wohl noch mit einer älteren Version von perl, jedenfalls hab ich die Geschichte selbst nie zum Laufen gebracht. Ich könnte aber nochmal nach dem Buch suchen...
Grüße, Skrilax
-