Хочется потренироваться в разработке серверных приложений.
Возникла идея сделать HTTP сервер без динамического контента ориентированный на маштабируемость и максимальную производительность.
Использоваться он может:
— самостоятельно для статических сайтов
— в паре с другим сервером. статический сервер будет отвечать за хранение и выдачу например картинок, а динамический контент с ссылками на эти картинки будет выдавать другой сервер.
Во втором варианте основной сервер разгружается так как занимается только диманическим контентом, а статический сервер проще сделать хорошо маштабируемым.
Имеет право на жизнь такая идея или это мертвый путь?
P.S. Понятно, что в качестве тренировки вообще можно делать, все что угодно, но хочется, чтобы то что получилось (если получится) могло кому-нибудь пригодиться
Здравствуйте, RailRoadMan, Вы писали:
RRM>Возникла идея сделать HTTP сервер без динамического контента ориентированный на маштабируемость и максимальную производительность.
Здравствуйте, RailRoadMan, доброго времени суток.
У меня давно была идея написать что либо подобное для тренировки и собственно лучшего понимания работы серверного по.
А на каком языке планируется разработка
Здравствуйте, Shock, Вы писали:
S>Здравствуйте, RailRoadMan, доброго времени суток. S>У меня давно была идея написать что либо подобное для тренировки и собственно лучшего понимания работы серверного по. S>А на каком языке планируется разработка
На С++. Она не то чтобы планируется, она размышляется пока.
Где-то год назад я тоже "закосячил" свой сервер. "Закосячил", по тому, что он упорно жлар память и дох от еейной нехватки.
Правда не всегда И тогда это все начинало пожирать виртуальную пямять...
Ну удивляться было собственно нечему: в него был встроен мой язык программирования. Приходилось каждый день проверять и перезапускать. Файлы народу раздавал(фильмы там, музыку). В общем прикольно было.
RRM>Хочется потренироваться в разработке серверных приложений.
Мне тоже хотелось(хотя это был уже 2, написанный заново сервер) И сейчас хочется: еще быстрей и красивей. Сижу пишу.
RRM>Возникла идея сделать HTTP сервер без динамического контента ориентированный на маштабируемость и максимальную производительность.
Эт получается файловый сервер. Начни с него, он проще.
RRM>Использоваться он может: RRM>- самостоятельно для статических сайтов
RRM>- в паре с другим сервером. статический сервер будет отвечать за хранение и выдачу например картинок, а динамический контент с ссылками на эти картинки будет выдавать другой сервер.
RRM>Во втором варианте основной сервер разгружается так как занимается только диманическим контентом, а статический сервер проще сделать хорошо маштабируемым.
RRM>Имеет право на жизнь такая идея или это мертвый путь?
Пробуй. Время подскажет.
RRM>P.S. Понятно, что в качестве тренировки вообще можно делать, все что угодно, но хочется, чтобы то что получилось (если получится) могло кому-нибудь пригодиться
В начале пригодиться может только тебе. А потом и в проектах( куда я его только не запихивал.) Технология то неплохая.
Мне было "весело". Да и интернет я люблю. Хотелось не только сайтики создавать, но и заняться тем, на чем они строятся. (Серверами тоесть.)
У тебя какие знания языка? (Интересно)
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, RailRoadMan, Вы писали: RRM>Имеет право на жизнь такая идея или это мертвый путь?
Гм. Вообще-то — да на оба вопроса
1. Да, такая идея право на жизнь имеет. Вообще все современные HTTP-сервера так и работают: статика обрабатывается встроенным движком, динамика отдается на обработку внешнему приложению. Меняется только способ интеграции внешнего приложения: CGI, FastCGI, ISAPI, Apache Module, Windows HTTP API, IIS Integrated Pipeline.
2. Да, это мертвый путь. Порвать существующие HTTP-сервера на статике практически невозможно. Ну, например, что ты сможешь противопоставить http.sys в IIS 6/7? Там обработка статики вообще происходит целиком в Kernel Mode, что дает скорострельность, невоспроизводимую классическим user mode приложением. Просто между собой договариваются три драйвера — TCP/IP, HTTP, и FS. На линуксах существуют nginx и lighttpd, которые тоже работают на пределе возможного. У тебя есть идея, которая позволит как-то существенно улучшить скорострельность сервера на статике? А за счет чего?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shock, Вы писали:
S>Если будут интересные идеи хотел бы тоже внести кусочек своего опыта в разработке на плюсах S>Просто хочеться чего то красивого, а не грёбаные БД и веб
Идей на самом деле есть бесконечное количество. Нужно просто их видеть.
Лично мне приходится от них отстреливаться
Чем тебе не нравится веб и БД? :| (Я щас БД пишу.)
Встроенные сервера это хорошо, но там "стандартные" решения.
Вот мне например сейчас нужен очень быстрый сервер, под конкретную задачу. И я пишу свой, потому что: это интересно, это развитие собственных разработок, я так привык. (Еще возможность полностью наплевать на платформу и офигенная переносимость. Делай с кодом чего хочешь.)
Я пропишу всю логику в самом сервере. Загружу все картинки. (Их немного, и больше не придется их читать с диска.)
Что может быть быстрее? Ну явно не сервер с PHP и остальной компаней.
Ага, на статике, а я тут про динамику.
Ну можно попытаться сделать более лучшее управление посылкой файлов. (Если файлы большие).
Ну можно поизвращаться. Тут все зависит от задач сервера. Может чего и получится. В общем это для интересующихся.
Хм, хотя, как я говорил, можно запихнуть в программу. Как запихнуть стандартные в программу не знаю, не интересовался.
PS. Многие пользуются Апачем.
Народ, какой у вас опыт программирования? И насколько красивое вы хотите? Это сервер? (Или приложение с графикой?)
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали: MSV>Народ, какой у вас опыт программирования? И насколько красивое вы хотите? Это сервер? (Или приложение с графикой?)
У меня 7 лет опыта работы с плюсами 3 года работы C# (Forms, ASP,...) MsSql года 3-4
В общем так немного конечно, но я стараюсь
Здравствуйте, Shock, Вы писали:
S>Здравствуйте, MikelSV, Вы писали: MSV>>Народ, какой у вас опыт программирования? И насколько красивое вы хотите? Это сервер? (Или приложение с графикой?) S>У меня 7 лет опыта работы с плюсами 3 года работы C# (Forms, ASP,...) MsSql года 3-4 S>В общем так немного конечно, но я стараюсь
У меня с С++ меньше. Но начиная с бейсика скоро будет 10 лет.
Я правда, языками постоянно занимаюсь
Так что-ты хочешь создать? В каком направлении?
Если красивое. Я сейчас пытаюсь хранитель экрана сделать. Тоесть уже пишу под него инсталлятор. Для меня это красиво.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Если красивое. Я сейчас пытаюсь хранитель экрана сделать. Тоесть уже пишу под него инсталлятор. Для меня это красиво.
М.Б. я извращенец , но если задача верно декомпозирована, грамотно иерархия поставлена то для меня это красиво
По работе просто приходиться писать заказные вещи где нет творчества, а для себя хочется чего нить красивого
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, RailRoadMan, Вы писали: RRM>>Имеет право на жизнь такая идея или это мертвый путь? S>Гм. Вообще-то — да на оба вопроса S>1. Да, такая идея право на жизнь имеет. Вообще все современные HTTP-сервера так и работают: статика обрабатывается встроенным движком, динамика отдается на обработку внешнему приложению. Меняется только способ интеграции внешнего приложения: CGI, FastCGI, ISAPI, Apache Module, Windows HTTP API, IIS Integrated Pipeline.
Я имел в виду немнуго другую идею, сервер вообще не поддерживает динамику. Динамику поддерживает отдельный сервер, он генерит динамические страницы, но ведь на них как правило есть картинки, ктр грузятся по линку. Вот динамический сервер и прописывает линк на статический сервер. Т.е. при загрузке страницы клиент берет данный с двух серверов. Получается два коннекта вместо одного, с точки зрения клиента — это хуже (интересно насколько и заметно ли вообще)
S>2. Да, это мертвый путь. Порвать существующие HTTP-сервера на статике практически невозможно. Ну, например, что ты сможешь противопоставить http.sys в IIS 6/7? Там обработка статики вообще происходит целиком в Kernel Mode, что дает скорострельность, невоспроизводимую классическим user mode приложением. Просто между собой договариваются три драйвера — TCP/IP, HTTP, и FS. На линуксах существуют nginx и lighttpd, которые тоже работают на пределе возможного. У тебя есть идея, которая позволит как-то существенно улучшить скорострельность сервера на статике? А за счет чего?
Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы.
P.S. Я реалист порвать существующие сервера я особенно не рассчитывваю
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, RailRoadMan, Вы писали: RRM>>>Имеет право на жизнь такая идея или это мертвый путь? S>>Гм. Вообще-то — да на оба вопроса S>>1. Да, такая идея право на жизнь имеет. Вообще все современные HTTP-сервера так и работают: статика обрабатывается встроенным движком, динамика отдается на обработку внешнему приложению. Меняется только способ интеграции внешнего приложения: CGI, FastCGI, ISAPI, Apache Module, Windows HTTP API, IIS Integrated Pipeline.
RRM>Я имел в виду немнуго другую идею, сервер вообще не поддерживает динамику. Динамику поддерживает отдельный сервер, он генерит динамические страницы, но ведь на них как правило есть картинки, ктр грузятся по линку. Вот динамический сервер и прописывает линк на статический сервер. Т.е. при загрузке страницы клиент берет данный с двух серверов. Получается два коннекта вместо одного, с точки зрения клиента — это хуже (интересно насколько и заметно ли вообще)
Клиенту, если честно пофигу. Тут другая проблема программа занимает порт( обычно 80 ), второй придется работать по другому порту.
S>>2. Да, это мертвый путь. Порвать существующие HTTP-сервера на статике практически невозможно. Ну, например, что ты сможешь противопоставить http.sys в IIS 6/7? Там обработка статики вообще происходит целиком в Kernel Mode, что дает скорострельность, невоспроизводимую классическим user mode приложением. Просто между собой договариваются три драйвера — TCP/IP, HTTP, и FS. На линуксах существуют nginx и lighttpd, которые тоже работают на пределе возможного. У тебя есть идея, которая позволит как-то существенно улучшить скорострельность сервера на статике? А за счет чего?
RRM>Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы.
А тут серверу пофигу. Вот если у тебя два сервера(два компьютера), тогда другое дело. И живучесть повышается.
RRM>P.S. Я реалист порвать существующие сервера я особенно не рассчитывваю
А это собственно и не нужно.
Я считаю, что если создавать сервер, то рассчитывать на использование самому. Поиграться с ним, для лучшего понимания. Развернуть в интернете.
S>М.Б. я извращенец , но если задача верно декомпозирована, грамотно иерархия поставлена то для меня это красиво S>По работе просто приходиться писать заказные вещи где нет творчества, а для себя хочется чего нить красивого
Ты б видел, какой я извращенец.
Знаешь, что такое md5? Так во я свою такую написал? А регялярные выражения? Разработал для выдергивания нужного текста с html страниц. БДшка, так, сервер уже был, еще есть сервер кодирующий музыку, MyltiTypes — как аналог variantа, язык программирования(страшно глючивший при ошибках в коде), еще окошки Windowsные с контролами (Аналог. Они любят тормозить при перерисовке)... И над чем я только не извращался Ой, а одних матриц 3 поколения!
А это фильм знаешь? Тоже я снял.
Щас мечтаю сервисы в интернете разрабатывать. Счетчики посещаемости для начала. У меня такие на PHP есть(году в 2003 написал). Вот хочу наконец на реальной платформе сделать. Только надо чтоли людей больше, а то все один, да один.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
RRM>>Я имел в виду немнуго другую идею, сервер вообще не поддерживает динамику. Динамику поддерживает отдельный сервер, он генерит динамические страницы, но ведь на них как правило есть картинки, ктр грузятся по линку. Вот динамический сервер и прописывает линк на статический сервер. Т.е. при загрузке страницы клиент берет данный с двух серверов. Получается два коннекта вместо одного, с точки зрения клиента — это хуже (интересно насколько и заметно ли вообще)
MSV>Клиенту, если честно пофигу. Тут другая проблема программа занимает порт( обычно 80 ), второй придется работать по другому порту.
Не вижу тут никаких проблем с портами, номер порта на работу сервера не влияет.
S>>М.Б. я извращенец , но если задача верно декомпозирована, грамотно иерархия поставлена то для меня это красиво S>>По работе просто приходиться писать заказные вещи где нет творчества, а для себя хочется чего нить красивого
MSV>Ты б видел, какой я извращенец. MSV>Знаешь, что такое md5? Так во я свою такую написал? А регялярные выражения? Разработал для выдергивания нужного текста с html страниц. БДшка, так, сервер уже был, еще есть сервер кодирующий музыку, MyltiTypes — как аналог variantа, язык программирования(страшно глючивший при ошибках в коде), еще окошки Windowsные с контролами (Аналог. Они любят тормозить при перерисовке)... И над чем я только не извращался Ой, а одних матриц 3 поколения!
Мне как-то ближе подход Shock-а, хочется не что-то конкретно реализовать, а сделать это красиво и правильно.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Порвать можно за счет того, что это сервер — чистая статика.
Нельзя.
Смотри на то как устроен lighttpd
В лучшем случае ты сможешь повторить лайти.
Ибо лайти это конечный автомат обслуживающий кучу асинхронных операций ввода/вывода + немного логики.
Вся тяжолая логика отдается fastcgi демонам которые работают на пулах потоков.
RRM>Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы.
В случае с лайти динамически сервер это fastcgi демон который общается с лайти через локальные сокеты.
RRM>P.S. Я реалист порвать существующие сервера я особенно не рассчитывваю
А нафига тогда?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
АК>Как кстати твоя ОС поживает?
Моя ОС ждет компилятора. Она грузится и рисует заставку квадратиками 80х24
У меня постоянно возникают новые идеи. Щас допишу БД, закончу один (если повезет) очень крутой проект. (Он собственно покажет, чего я стою.) Вот тогда возьмусь за компилятор, а там и до оси недалеко.
>Не вижу тут никаких проблем с портами, номер порта на работу сервера не влияет.
Два сервера по 80 не запустишь. а так больше проблем нет.
>Мне как-то ближе подход Shock-а, хочется не что-то конкретно реализовать, а сделать это красиво и правильно. супер фразочка.
>А нафига тогда?
А вот душа требует! Ведь хочется почувствовать кайф от работы! Я когда БД начал писать такой кайф ловил под конец дня, ощущая, что день был не напрасным.
Душа чиста, прекрасна,
И в голо все ясно,
И тормозит слегка.
(Че-то опять на стихи потянуло, вот как рифму увижу, так и тянет.)
Че-то меня последнее время действительно подтормаживает.
Меня больше радует процесс. Я заваливаюсь на обслуживании "законченного".
Ну хакеры, чего хотим-то? Могу помочь советом, только определитесь, что вы хотите делать.
Сервер?
Берем: socket(), bind(), listen(), accept(), connect(), recv() и send(). Я недавно select изучил Раньше никогда не пользовался. А оказалось, что в линуксе без него никак.
Вы какими функциями работать думаете? Нужна ли кроссплатформенность?
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, RailRoadMan, Вы писали:
RRM>Я имел в виду немнуго другую идею, сервер вообще не поддерживает динамику. Динамику поддерживает отдельный сервер, он генерит динамические страницы, но ведь на них как правило есть картинки, ктр грузятся по линку. Вот динамический сервер и прописывает линк на статический сервер. Т.е. при загрузке страницы клиент берет данный с двух серверов. Получается два коннекта вместо одного, с точки зрения клиента — это хуже (интересно насколько и заметно ли вообще)
Lighttpd/Varnish/nginx примерно так и работают.
RRM>Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы.
Не получится. Например, lighttpd в Линуксе умеет использовать sendfile. То есть, после того, как был распарсен HTTP-заголовок, сервер дает указание ядру передать данные из файла в сокет. На уровне ядра это реализовано прямой передачей страниц из отображенного в память файла в сетевой драйвер. При этом в идеале даже не происходит ни одного копирования данных. В Windows примерно то же самое делается с помощью ядерного кэша в IIS'е.
Но при этом Lighttpd может быть настроен на работу фронтендом к серверу на Java/PHP/Perl/..., без всякого ухудшения производительности статики.
Единственная возможность улучшения, которую я сейчас вижу — это сделать эффективную систему передачи больших файлов (сотни файлов в сотни мегабайт) за счет интеллектуальной системы планирования IO. Но и то, очень вряд ли.
а так больше проблем нет.
супер фразочка.
