Здравствуйте, RailRoadMan, Вы писали:
RRM>Порвать можно за счет того, что это сервер — чистая статика.
Нельзя.
Смотри на то как устроен lighttpd
В лучшем случае ты сможешь повторить лайти.
Ибо лайти это конечный автомат обслуживающий кучу асинхронных операций ввода/вывода + немного логики.
Вся тяжолая логика отдается fastcgi демонам которые работают на пулах потоков.
RRM>Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы.
В случае с лайти динамически сервер это fastcgi демон который общается с лайти через локальные сокеты.
RRM>P.S. Я реалист порвать существующие сервера я особенно не рассчитывваю
А нафига тогда?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
siv>>Посмотрите на libpion + asio. siv>>Там есть еще, что доделывать, но подход очень Сам бы поучавствовал, но нет времени... siv>>Если у вас есть свободное время, руки+голова, то "контрибутьте" в реально используемые проекты...
MSV>Чужое править неохота. Разбираться лень. Хочется делать своими руками с нуля.
Знаешь пословицу про обучение на чужих ошибках
Если не разобрался с чужим, то не факт, что своё сделаешь не хуже.
MSV>Думаю на следующей неделе форум начну делать. Еще хочу собственную почту. Там тоже интересные вопросы: принять, сохранить, показать и удалить + web интерфейс. (Простенькую почту по идее сделать не трудно, сложнее будет выбрать и прикрутить спам-фильтр. Или написать самому )
Мне вспомнился эпизод из Формулы любви, когда Калиостро встретил ранним утром того влюбленного юношу-графа с двумя оседланными лошадьми, и как он прокомментировал ответ юноши на вопрос, зачем ему 2 лошади.
Хочется потренироваться в разработке серверных приложений.
Возникла идея сделать 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-а, хочется не что-то конкретно реализовать, а сделать это красиво и правильно.
АК>Как кстати твоя ОС поживает?
Моя ОС ждет компилятора. Она грузится и рисует заставку квадратиками 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. Но и то, очень вряд ли.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Я имел в виду немнуго другую идею, сервер вообще не поддерживает динамику. Динамику поддерживает отдельный сервер, он генерит динамические страницы, но ведь на них как правило есть картинки, ктр грузятся по линку. Вот динамический сервер и прописывает линк на статический сервер. Т.е. при загрузке страницы клиент берет данный с двух серверов. Получается два коннекта вместо одного, с точки зрения клиента — это хуже (интересно насколько и заметно ли вообще) C>Lighttpd/Varnish/nginx примерно так и работают.
RRM>>Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы. C>Не получится. Например, lighttpd в Линуксе умеет использовать sendfile. То есть, после того, как был распарсен HTTP-заголовок, сервер дает указание ядру передать данные из файла в сокет. На уровне ядра это реализовано прямой передачей страниц из отображенного в память файла в сетевой драйвер. При этом в идеале даже не происходит ни одного копирования данных. В Windows примерно то же самое делается с помощью ядерного кэша в IIS'е.
C>Но при этом Lighttpd может быть настроен на работу фронтендом к серверу на Java/PHP/Perl/..., без всякого ухудшения производительности статики.
C>Единственная возможность улучшения, которую я сейчас вижу — это сделать эффективную систему передачи больших файлов (сотни файлов в сотни мегабайт) за счет интеллектуальной системы планирования IO. Но и то, очень вряд ли.
Доверяй, но проверяй. Хотелось бы конечно самому убедиться в их скорости. Да только времени к сожалению нет.
Создай хоть наикрутейший сервер, он никому не будет нужен. (Ну может потом разрекламируешь).
Если и создавать, так сразу подумать о применении.
Например в интернете какие-нибудь данные раздавать.
Хм, вообще-то смотрю перспективы не очень. Ну куда сейчас можно такой сервер поставить?
Хотя как посмотреть и что у вас получится.
Что вы хотите получить в конце? Знания и опыт, коммерческий продукт, чувство победы разума над машиной?
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, RailRoadMan, Вы писали: RRM>Я имел в виду немнуго другую идею, сервер вообще не поддерживает динамику. Динамику поддерживает отдельный сервер, он генерит динамические страницы, но ведь на них как правило есть картинки, ктр грузятся по линку. Вот динамический сервер и прописывает линк на статический сервер. Т.е. при загрузке страницы клиент берет данный с двух серверов. Получается два коннекта вместо одного, с точки зрения клиента — это хуже (интересно насколько и заметно ли вообще)
Гм. Попробуй познакомиться с архитектурой современных HTTP серверов. Клиент вообще не в курсе, с какого количества серверов он берет данные. Точнее, есть небольшая разница — в случае одной точки входа клиент может использовать keepalive, чтобы экономить трафик.
RRM>Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы.
Ты, наверное, не понял. В современном HTTP сервере есть несколько разных частей. В частности, статика и динамика обрабатываются почти независимо. Так что динамический сервер (к примеру, ASP.NET, Tomcat, PHP, или еще кто-то) не обрабатывает динамикиу, за счет чего он разгружен. А статика бегает в отдельном компоненте, сделанном чисто для нее. Еще раз подчеркиваю, что высокоэффективный HTTP сервер статики работает в режиме ядра ОС, где быстродействие близко к реалтайму. При этом у него нет проблемы конфликта портов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
RRM>>Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы. S>Ты, наверное, не понял. В современном HTTP сервере есть несколько разных частей. В частности, статика и динамика обрабатываются почти независимо. Так что динамический сервер (к примеру, ASP.NET, Tomcat, PHP, или еще кто-то) не обрабатывает динамикиу, за счет чего он разгружен. А статика бегает в отдельном компоненте, сделанном чисто для нее. Еще раз подчеркиваю, что высокоэффективный HTTP сервер статики работает в режиме ядра ОС, где быстродействие близко к реалтайму. При этом у него нет проблемы конфликта портов.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Sinclair, Вы писали:
RRM>>>Порвать можно за счет того, что это сервер — чистая статика. Кроме того разгрузится (а может и нет) динамическйи сервер, так как он не будет обрабатывать статические запросы. S>>Ты, наверное, не понял. В современном HTTP сервере есть несколько разных частей. В частности, статика и динамика обрабатываются почти независимо. Так что динамический сервер (к примеру, ASP.NET, Tomcat, PHP, или еще кто-то) не обрабатывает динамикиу, за счет чего он разгружен. А статика бегает в отдельном компоненте, сделанном чисто для нее. Еще раз подчеркиваю, что высокоэффективный HTTP сервер статики работает в режиме ядра ОС, где быстродействие близко к реалтайму. При этом у него нет проблемы конфликта портов.
RRM>Да понял-понял. Ловить тут нечего.
Было бы желание, что словить найдется
Знаете, я занимаюсь философией. Так вот недавно я понял(ко мне пришло прозрение) что "интересных" задач в программировании бесконечность. Я это и раньше знал, но с прозрением это как с красным дипломом.
Нужно только подобрать для программы подходящую нишу.
Знаете, когда я начинаю заниматься чем-то, то начинаю видеть, куда можно пристроить программку.
Я вот форум хочу написать. Но не php, которых дофига а на С++, которых не припоминаю. Это тоже сервер, но с направлением. Он будет наааамного быстрее phpшного. А если приделать ему мобильность, то вообще класс.
Идей бесконечность выбирайте
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
MSV>Я вот форум хочу написать. Но не php, которых дофига а на С++, которых не припоминаю. Это тоже сервер, но с направлением. Он будет наааамного быстрее phpшного. А если приделать ему мобильность, то вообще класс.
Клёвая идея, имеется в виду ISAPI фильтр?
Здравствуйте, Shock, Вы писали:
S>Здравствуйте, MikelSV, Вы писали:
MSV>>Я вот форум хочу написать. Но не php, которых дофига а на С++, которых не припоминаю. Это тоже сервер, но с направлением. Он будет наааамного быстрее phpшного. А если приделать ему мобильность, то вообще класс. S>Клёвая идея, имеется в виду ISAPI фильтр?
Я даже таких слов то не знаю. (Почитал, узнал)
Нет, программку с использованием стандартных соккетов.
Берем (Лучше пишем) сервер и превращаем его в форум.
Я теперь за кроссплатформенность. (Просто у меня сервер под линуксом )
И не придется таскать с собой кучу лишних (и можно сказать совершенно ненужных) библиотек. Это и есть мобильность.
Если вас беспокоят потери в скорости, это можно списать на мобильность. К тому же какова вероятность, что вы будете использовать сервер на все 100%? Если не будете разница еще незаметнее. И еще: системка поличится более компактней, что тоже по идее должно дать прирост в скорости.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV> Я вот форум хочу написать. Но не php, которых дофига а на С++, которых не припоминаю. Это тоже сервер, но с направлением.
[...] MSV>Если вас беспокоят потери в скорости, это можно списать на мобильность.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Здравствуйте, MikelSV, Вы писали:
MSV>> Я вот форум хочу написать. Но не php, которых дофига а на С++, которых не припоминаю. Это тоже сервер, но с направлением. АК>[...] MSV>>Если вас беспокоят потери в скорости, это можно списать на мобильность.
АК>Начни с http://www.kegel.com/c10k.html. Как раз для тех, кто пишет серверы с направлением.
Серверы с направлением я пишу уже давно. И на практике понял разницу между Windows и линуксом
Статейка интересная, но мне в общем-то ничего не надо, сам все придумаю
Сначала нужно написать. Подгонять под определенную систему можно потом, если потребность будет.
Я тут недавно поизучал(почитал) как пишутся программы, так вот народ хочет быстро что-то написать, главное чтобы работало. А оптимизировать потом. Оптимизировать я люблю по ходу дела, но вот подгонять под систему это потом. Тем более, что хочу запускать его под Windowsом. (Линукс пока подождет)
(Тем более, что на меня свалился еще один проект, который не должен ждать: виртуальные файлы. )
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
АК>>Начни с http://www.kegel.com/c10k.html. Как раз для тех, кто пишет серверы с направлением. MSV>Серверы с направлением я пишу уже давно. И на практике понял разницу между Windows и линуксом
А почему ?
MSV>Я тут недавно поизучал(почитал) как пишутся программы, так вот народ хочет быстро что-то написать, главное чтобы работало. А оптимизировать потом. MSV> Оптимизировать я люблю по ходу дела, но вот подгонять под систему это потом. Тем более, что хочу запускать его под Windowsом. (Линукс пока подождет)(Тем более, что на меня свалился еще один проект, который не должен ждать: виртуальные файлы. )
Интересная у тебя работа однако, задачи все такие ммм... концептуальные. Где работаешь если не секрет?
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Здравствуйте, MikelSV, Вы писали:
АК>>>Начни с http://www.kegel.com/c10k.html. Как раз для тех, кто пишет серверы с направлением. MSV>>Серверы с направлением я пишу уже давно. И на практике понял разницу между Windows и линуксом АК>А почему ?
А по тому что в Windowsе оказалось проще программировать, хотя его все ругают.
MSV>>Я тут недавно поизучал(почитал) как пишутся программы, так вот народ хочет быстро что-то написать, главное чтобы работало. А оптимизировать потом. MSV>> Оптимизировать я люблю по ходу дела, но вот подгонять под систему это потом. Тем более, что хочу запускать его под Windowsом. (Линукс пока подождет)(Тем более, что на меня свалился еще один проект, который не должен ждать: виртуальные файлы. ) АК>Интересная у тебя работа однако, задачи все такие ммм... концептуальные. Где работаешь если не секрет?
Работаю то я на секретном предприятии, но почти все, о чем на форуме спрашиваю к работе не относится
(По работе хватает сделанных ранее разработок.)
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
RRM>Хочется потренироваться в разработке серверных приложений. RRM>Возникла идея сделать HTTP сервер без динамического контента ориентированный на маштабируемость и максимальную производительность.
Посмотрите на libpion + asio.
Там есть еще, что доделывать, но подход очень Сам бы поучавствовал, но нет времени...
Если у вас есть свободное время, руки+голова, то "контрибутьте" в реально используемые проекты...
Здравствуйте, siv, Вы писали:
RRM>>Хочется потренироваться в разработке серверных приложений. RRM>>Возникла идея сделать HTTP сервер без динамического контента ориентированный на маштабируемость и максимальную производительность.
siv>Посмотрите на libpion + asio. siv>Там есть еще, что доделывать, но подход очень Сам бы поучавствовал, но нет времени... siv>Если у вас есть свободное время, руки+голова, то "контрибутьте" в реально используемые проекты...
Чужое править неохота. Разбираться лень. Хочется делать своими руками с нуля.
Думаю на следующей неделе форум начну делать. Еще хочу собственную почту. Там тоже интересные вопросы: принять, сохранить, показать и удалить + web интерфейс. (Простенькую почту по идее сделать не трудно, сложнее будет выбрать и прикрутить спам-фильтр. Или написать самому )
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, siv, Вы писали:
siv>>>Посмотрите на libpion + asio. siv>>>Там есть еще, что доделывать, но подход очень Сам бы поучавствовал, но нет времени... siv>>>Если у вас есть свободное время, руки+голова, то "контрибутьте" в реально используемые проекты...
MSV>>Чужое править неохота. Разбираться лень. Хочется делать своими руками с нуля. siv>Знаешь пословицу про обучение на чужих ошибках siv>Если не разобрался с чужим, то не факт, что своё сделаешь не хуже.
Конечно не факт. Но за это время успеешь научиться на своих. Мне кажется это намного лучше Это свой путь. Я просто не люблю ходить по чужим дорогам.
MSV>>Думаю на следующей неделе форум начну делать. Еще хочу собственную почту. Там тоже интересные вопросы: принять, сохранить, показать и удалить + web интерфейс. (Простенькую почту по идее сделать не трудно, сложнее будет выбрать и прикрутить спам-фильтр. Или написать самому )
siv>Мне вспомнился эпизод из Формулы любви, когда Калиостро встретил ранним утром того влюбленного юношу-графа с двумя оседланными лошадьми, и как он прокомментировал ответ юноши на вопрос, зачем ему 2 лошади.
Так какой был ответ? Поделись, тоже хочу посмеяться.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
siv>>Мне вспомнился эпизод из Формулы любви, когда Калиостро встретил ранним утром того влюбленного юношу-графа с двумя оседланными лошадьми, и как он прокомментировал ответ юноши на вопрос, зачем ему 2 лошади.
MSV>Так какой был ответ? Поделись, тоже хочу посмеяться.
Не, не скажу, а то кайф поломаю Лучше напиши P2P клиент свой и качни им фильм и посмотри на своём собственном плеере
Здравствуйте, siv, Вы писали:
siv>>>Мне вспомнился эпизод из Формулы любви, когда Калиостро встретил ранним утром того влюбленного юношу-графа с двумя оседланными лошадьми, и как он прокомментировал ответ юноши на вопрос, зачем ему 2 лошади.
MSV>>Так какой был ответ? Поделись, тоже хочу посмеяться. siv>Не, не скажу, а то кайф поломаю Лучше напиши P2P клиент свой и качни им фильм и посмотри на своём собственном плеере
Не поверишь, уже пишу. Написана часть интерфейса, протокол, логика.
Так, ага, вспомнил, мне не понравилась прошлая работа БД, стабильности было мало. В общем щас закончу БД, напишу ее линейную версию, потом форум, для тестирования, и тогда продолжу p2p.
Короче я последние 9 лет (эх бейсик ... html ... js .. php ... C++) почти всегда в работе. (Ну если не считать депрессий и запоев в игрушки.)
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Сам бы поучавствовал, но нет времени...
)
а так больше проблем нет.
выбирайте
