Thread View: pl.comp.networking
6 messages
6 total messages
Started by Stefan Jurczyk
Mon, 18 Nov 1996 12:03
Polski server WWW
Author: Stefan Jurczyk
Date: Mon, 18 Nov 1996 12:03
Date: Mon, 18 Nov 1996 12:03
43 lines
2961 bytes
2961 bytes
Witam... Od dluzszego czasu zajmuje sie wszystkim co jest zwiazane z protokolem HTTP. W wyniku mojej zabawy powstal eksperymentalny SERVER WWW. Server ten odroznial sie od istniejacych (Apache, NCSA, NetScape) faktem ze uzywam dosc jeszcze rzadko uzywanej metody watkowania na poziomie aplikacji. Czyli mowiac prosciej: server nie tworzy kolejnych procesow na kazde otwarte rownolegle polaczenie - co wystepowaly w/w serverach. Dzieki czemu ma on duzo mniejsze wymagania na pamiec, sprzet - rownoczesnie jest w stanie obsluzyc wiecej polaczen mniejszym kosztem oraz ma mniejszy czas "odpowiedzi" na zamowienie. Tamtem server byl napisany wyjatkowo eksperymentalnie (brak konfiguracji po skompilowaniu) - jedynie w celu rozpoznania technologi. W obecnej chwili server jest pisany calkowicie od nowa - ale juz jako produkt, ktory bedzie udostepniony swiatu. Glownymi cechami pisanego servera bedzie: - watkowanie sie na poziomie aplikacji - dzieki czemu jeden process server'a bedzie w stanie obsluzyc 120 (Linux/FreeBSD) do 250 (Irix) rownolegle otwartych polaczen, - zastosowanie tzw. modulow ladowanych dynamicznie - odpowiednika modulow ISAPI znanych z serverow Microsoft'a lub modulow znanych z Apache ale ladowanych w chwili ich uzycia z zewnetrznych biblotek so, dzieki czemu nie trzeba bedzie przekompilowywac server'a za kazda zmiana listy uzytych modolow. Moduly DLM beda tez mogly byc uzyte jako filtry na dane rozszerzenie czy mime-type (dzieki czemu na nich bedzie realizowana obsluga image map, cgi, asis, server include) oraz sterowac autoryzacja. Niestety niektore technologie uzyte w serverze inaczej sie implementuje na roznych unix'ach. Niestety standart Posix'a mimo ze istnieje, nie rozwiazuje wszystkich problemow - charakterystyczne jest ze "co unix to obyczaj". I to mala prosba: poszukuje (wspol)administratorow serverow Unix'owych innego typu niz FreeBSD i Irix, ktorzy mogliby udostepnic konto na swoich serverach w celu wykonania supportu tego server'a na dana platforme. Podejrzewam ze nie uda mi sie zdobyc kont na wszystkich platformach - wiec poszukiwane sa takze osoby ktore maja dostep do takich platform, znaja sie na programowaniu, maja troche wolnego czasu i pobawily by sie tym serverem lub udostepnily by mi swoje konto. na razie tyle Stefan Jurczyk steve@tme.man.szczecin.pl
Re: Polski server WWW
Author: Krzysztof Halasa
Date: Tue, 19 Nov 1996 09:11
Date: Tue, 19 Nov 1996 09:11
12 lines
1067 bytes
1067 bytes
"Stefan Jurczyk" <steve@tme.man.szczecin.pl> writes: > Glownymi cechami pisanego servera bedzie: > - watkowanie sie na poziomie aplikacji - dzieki czemu jeden process > server'a bedzie w stanie obsluzyc 120 (Linux/FreeBSD) do 250 (Irix) > rownolegle otwartych polaczen, To jakies ograniczenie wynikajace z architektury tych systemow, czy jeszcze z czegos innego? -- Krzysztof Halasa Network Administrator of The Palace of Youth in Warsaw
Re: Polski server WWW
Author: Stefan Jurczyk
Date: Tue, 19 Nov 1996 12:32
Date: Tue, 19 Nov 1996 12:32
17 lines
1359 bytes
1359 bytes
Krzysztof Halasa <khc@hq.pm.waw.pl> wrote in article <m3u3qmzbxd.fsf@hq.pm.waw.pl>... > > Glownymi cechami pisanego servera bedzie: > > - watkowanie sie na poziomie aplikacji - dzieki czemu jeden process > > server'a bedzie w stanie obsluzyc 120 (Linux/FreeBSD) do 250 (Irix) > > rownolegle otwartych polaczen, > > To jakies ograniczenie wynikajace z architektury tych systemow, czy > jeszcze z czegos innego? Ograniczenie ilosci uchytow/handli (czy jak to nazwac), ktore mozna przykazac jako argument do funkcji select (). To nie znaczy ze caly server jest ograniczony do takiej ilosc polaczen - mozna uzyc kilka procesow. Stefan Jurczyk
Re: Polski server WWW
Author: Jan Rychter
Date: Tue, 19 Nov 1996 23:28
Date: Tue, 19 Nov 1996 23:28
23 lines
1833 bytes
1833 bytes
(ustawiajcie porządnie Followup-To: !!!) >>>>> "Stefan" == Stefan Jurczyk <steve@tme.man.szczecin.pl>: Stefan> Krzysztof Halasa <khc@hq.pm.waw.pl> wrote in article Stefan> <m3u3qmzbxd.fsf@hq.pm.waw.pl>... >> > Glownymi cechami pisanego servera bedzie: > - watkowanie sie na >> poziomie aplikacji - dzieki czemu jeden process > server'a bedzie w >> stanie obsluzyc 120 (Linux/FreeBSD) do 250 (Irix) > rownolegle >> otwartych polaczen, >> >> To jakies ograniczenie wynikajace z architektury tych systemow, czy >> jeszcze z czegos innego? Stefan> Ograniczenie ilosci uchytow/handli (czy jak to nazwac), ktore Stefan> mozna przykazac jako argument do funkcji select (). Hmm. Mówisz o ograniczeniu liczby otwartych uchwytów plików (deskryptorów) na proces? W dokumentacji select() nie znalazłem informacji o dodatkowych ograniczeniach. Jeżeli to pierwsze, w Linuxie ten limit daje się dość łatwo podnieść. --J.
Re: Polski server WWW
Author: Piotr Kucharski
Date: Thu, 21 Nov 1996 21:40
Date: Thu, 21 Nov 1996 21:40
11 lines
1172 bytes
1172 bytes
Stefan Jurczyk <steve@tme.man.szczecin.pl> wrote: > Ograniczenie ilosci uchytow/handli (czy jak to nazwac), ktore mozna > przykazac jako argument do funkcji select (). hm, a nie lepiej poll() ? z tego co wiem, używano select() w serverach irc, co powodowało znaczne opóźnienia. po wprowadzeniu poll() i powtórnego czytania fds znacznie się poprawiło. -- <A HREF="http://akson.sgh.waw.pl/~chopin"> Piotr 'Beeth' Kucharski </A>
Re: Polski server WWW
Author: Stefan Jurczyk
Date: Fri, 22 Nov 1996 14:33
Date: Fri, 22 Nov 1996 14:33
16 lines
1328 bytes
1328 bytes
Piotr Kucharski <chopin@sgh.waw.pl> wrote in article <572i8g$dks@onyx.sgh.waw.pl>... > Stefan Jurczyk <steve@tme.man.szczecin.pl> wrote: > > Ograniczenie ilosci uchytow/handli (czy jak to nazwac), ktore mozna > > przykazac jako argument do funkcji select (). > > hm, a nie lepiej poll() ? > z tego co wiem, używano select() w serverach irc, co powodowało znaczne > opóźnienia. po wprowadzeniu poll() i powtórnego czytania fds znacznie > się poprawiło. Tylko ze poll'a nie ma we wszystkich unix'ach a select () jest. Stefan Jurczyk
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads