[РЕШЕНО] Вебсервер: логика маршрутизации

[V1KT0P]

Можно и так конечно, но этот вариант мне не нравится. Ради простейшей в общем-то ситуации...

Регистратора соответствия хостов сайтам - да. Но не запросов. Хост - составная часть в запросе.

То есть делегировать плагинам возможность устанавливать статус ответа? Этот вариант мне понятен, он вроде как сам собой напрашивается, но мне не хочется передавать таковые полномочия плагинам. В Апаче, вроде, этого нет. Заголовки там всякие - это пожалуйста, а вот статус... Да и ситуация с иконкой говорит о том, что могут возникнуть всяческие недоразумения, что приведёт к снижению производительности. То есть подобные вещи, по идее, не должны касаться сайта. Он там у себя колупается в своей песочнице, и не особо лезет на сервер. Это было бы гут.

Снова ты не понимаешь. Допустим запускается сервер. У сервера есть два плагина forumPlugin и newsPlugin. Каждый из них регистрирует обработчик.
forumPlugin просто регистрирует forum.
newsPlugin регистрирует регулярку которая проверяет что запрос имеет вид даты типа 2012/05/01.
Далее рассмотри запросы:
forum/thread_9000
Сервер сперва проверяет наличие обработчика forum, находит его и передает ему запрос thread_9000. Обработчик парсит его и получает thread и 9000. По логике первое значение это команда, в данном случае thread возвращает страницу с темой номер 9000.
forum/post_100500
Тоже самое но возвращается страница показывающая только одно собщение номер 100500.
forum/blabla
Тоже самое но плагин не находит команду blabla. Если плагин не предусмотрел вывод сообщения о том что темы нет, то просто возращает серверу ошибку. Сервер уже разбирается что делать, то ли кидать на главную то-ли ошибку 404. Если же плагин предусмотрел ошибку то либо показ ошибки либо переброска на главную страницу форума.
2012/05/01/Super_News
Сервер сперва проверяет наличие обработчика 2012, не находит. Дальше проверяет обработчик регулярок. Находит обработчик newsPlugin, и передает ему строку 2012/05/01/Super_News. Новостной плагин парсит строку и выдает страницу новости. Если нету то либо сообщение об ошибке из плагина, либо переадрисация на главную новостей или сайта либо отдача ошибки серверу, который сам решит что делать на главную переадресовать или ошибку послать.
2013/05/01/Blabla
Тоже самое но ошибка.
favicon.ico
Сервер проверяет на наличие обработчика favicon.ico, не находит. Дальше проверяет обработчик регулярок. Тоже не находит. Дальше проверяет на наличие файла на диске. Если не находит то отсылает 404 (как это делает апач).
blablabla/bla
Тоже самое не находит обработчик blablabla и нет совпадений в регулярках. И файла такого нету, возвращает 404 (как это делает апач), либо перекидывает на главную сайта.

[alexis031182]

Да, понял теперь, что ты имеешь ввиду, но у меня как бы немного иначе построено. Рассматриваемые плагины forumPlugin и newsPlugin - это не что иное, как, например, forum.ru и news.ru (при этом на тот же forumPlugin может указывать и другой хост - forum.com). То есть плагин - это сайт.

Всё, что идёт после имени хоста относится уже к конкретному плагину. Допустим я предварительно зарегистрирую его обработчик. Тогда как-то на регулярках сайт должен будет описать все возможные варианты, ведь favicon и favicon.ico - могут присутствовать вместе: первый, как страница, а второй, как файл. И если, допустим, сейчас я, как разработчик конкретного сайта, не использую этот злосчастный favicon.ico, а потом добавлю его в папку на сервере, то мне придётся править код плагина, и выполнять перекомпиляцию dll-ки.

Это конечно вариант. Надо обмозговать идею с обработчиками, спасибо, V1KT0P. Просто я хотел сделать так, чтобы разработчик сайта по минимуму определял вариации, ограничившись, например, лишь чем-то подобным: /action и/или /controller/action и/или /module/controller/action.

[V1KT0P]

Тогда как-то на регулярках сайт должен будет описать все возможные варианты, ведь favicon и favicon.ico - могут присутствовать вместе: первый, как страница, а второй, как файл.

Повторю еще раз сперва проверяется наличие файла на диске, если его нет то происходит попытка вызова динамического контента. Проще всего для этого использовать nginx, он для этого и создавался.

[alexis031182]

Повторю еще раз сперва проверяется наличие файла на диске, ...

Да, да, это само собой. Я так и сделал пока.

... если его нет то происходит попытка вызова динамического контента.

Да, пожалуй. Только управление статусом ответа пихать в плагины не буду, лишь просто возврат ошибки, а сервер подытожит: 404 или ещё какой вариант.

Проще всего для этого использовать nginx, он для этого и создавался.

Статику мой сервер отдаст прекрасно и без nginx. Дополнительная прослойка не нужна в данном случае. Это больше для Апача актуально, где множество предварительных "настроечных" действий выполняется, прежде чем возникнет решение об отдаче.

Спасибо

[Bepec]

Совет - используй уже имеющиеся наработки. Сотни, если не тысячи разработчиков реализовали почти все идеи, которые можно реализовать в веб направлении. Ну или описали, почему не стоит реализовывать. Собственный велосипед - хорошо, поехали. А вот собственный танк уже плохо - то с места не сдвинется, то боезапас взорвётся

[alexis031182]

Совет - используй уже имеющиеся наработки.

Тогда и писать ничего не надо

Сотни, если не тысячи разработчиков реализовали почти все идеи, которые можно реализовать в веб направлении. Ну или описали, почему не стоит реализовывать.

Да наверное и без "почти" реализовали. Но мне сам процесс интересен. Разработка ради разработки - это не великий гут, но если прёт, то и хорошо ))

Собственный велосипед - хорошо, поехали. А вот собственный танк уже плохо - то с места не сдвинется, то боезапас взорвётся

Этот результат может получить в итоге и не только велосипедо-ваятель

А вообще, я поставил скорость работы программы в наивысший приоритет. Очень приятно смотреть, как в считанные миллисекунды формируется страница. Скорость передачи - тут уж не улучшить, от сетей зависит (сжатие само собой использовать буду), но наблюдать за скоростью работы сайта на С++ очень интересно. Особливо, когда вспоминаешь потуги пыхпыха.

[Bepec]

Извиняюсь, а можно результаты в студию?

Страница сгенерирована за 0.059 секунд. Запросов: 19. - Это форумный php выдаёт. А у вас? Стоило того?

[alexis031182]

Извиняюсь, а можно результаты в студию?

Пока в худшем и редком случае 0.002, а так 0.000 - 0.001. Но справедливости ради следует заметить, что я лишь собрал пока простенький статический документ и без обращения к БД (начал писать проект недавно). Ориентируюсь для себя на скорость 0.020 - таковую заметил у главной страницы гугла.

Страница сгенерирована за 0.059 секунд. Запросов: 19. - Это форумный php выдаёт. А у вас? Стоило того?

Форум на кеше сидит, если его отключить, вообще каюк будет. А если на кеше, да на С++, я думаю определённо имеет смысл хотя бы поэкспериментировать.

[V1KT0P]

Статику мой сервер отдаст прекрасно и без nginx. Дополнительная прослойка не нужна в данном случае. Это больше для Апача актуально, где множество предварительных "настроечных" действий выполняется, прежде чем возникнет решение об отдаче.

Я бы не стал недооценивать nginx. Ты вообще знаешь зачем стали ставить фронтэнды? Причина банальна: быстрое освобождение простаиваемых мощностей из-за того что отдача контента не моментальна. Решили все путем добавления фронтэнда которому сразу отдается запрос и осовобождаются ресурсы. А уж фронтэнд оптимизирован под отдавание контента. Также я бы на твоем месте сразу начертил на листе А1 архитектуру сервера. И по максимуму использовал бы динамическое подключение всего и вся. Чтоб одной кнопкой можно было на лету например заменить старый плагин форума на новый. Да да я все-таки за плагины. Зачем перекомпиливать весь сервер если можно всего навсего перекомпилить один плагин и заменить его без перезапуска онного сервера?

[alexis031182]

Я бы не стал недооценивать nginx. Ты вообще знаешь зачем стали ставить фронтэнды? Причина банальна: быстрое освобождение простаиваемых мощностей из-за того что отдача контента не моментальна. Решили все путем добавления фронтэнда которому сразу отдается запрос и осовобождаются ресурсы. А уж фронтэнд оптимизирован под отдавание контента.

Нет, нет, я не недооцениваю. Если понадобится, будет резон, то почему бы и нет. А статический контент я у себя отдаю сразу же, без дополнительных телодвижений в плагинах.

Также я бы на твоем месте сразу начертил на листе А1 архитектуру сервера.

Это хорошая идея. Документированием я не занимался ещё. Через одно место получается делаю ))

И по максимуму использовал бы динамическое подключение всего и вся. Чтоб одной кнопкой можно было на лету например заменить старый плагин форума на новый. Да да я все-таки за плагины. Зачем перекомпиливать весь сервер если можно всего навсего перекомпилить один плагин и заменить его без перезапуска онного сервера?

Именно так и сделано. Для изменения сайта достаточно заменить файл либы, ну и выполнить на сервере функция загрузки. То есть, что-то типа "горячего" переподключения имеется.

[alexis031182]

Всем привет

Кто может сейчас протестировать вебсервер? Помогите, пожалуйста

По этому адресу - http://78.81.31.38/qqq.webm - видеоролик (осторожно, 20 Мб)
Здесь http://78.81.31.38/novgorod.jpg - картинка

Спасибо

[V1KT0P]

По этому адресу - http://78.81.31.38/qqq.webm - видеоролик (осторожно, 20 Мб)
Здесь http://78.81.31.38/novgorod.jpg - картинка

Firefox 11, Chrome 18, картинка и видео работает нормально.

[alexis031182]

Firefox 11, Chrome 18, картинка и видео работает нормально.

Спасибо Сделал отдачу статики через смену буферов. Пока один наполняется, другой отдаёт данные в сеть. Затем меняются местами. Всё в отдельном потоке, чтобы не тормозить основной на приём новых соединений.

[alexis031182]

Добавил пару сайтов:
http://78.81.31.38/html/index.html
http://78.81.31.38/karma/index-3d-1.html

Заметил гуглобота. Пришла мысль вести информацию о ботах прямо на сервере (что, мол, такой-то приходил), и предоставлять её сайтам по требованию. Имеет смысл?

[V1KT0P]

Заметил гуглобота. Пришла мысль вести информацию о ботах прямо на сервере (что, мол, такой-то приходил), и предоставлять её сайтам по требованию. Имеет смысл?

Если собираешься монетизировать прогу, то чем больше статистики тем лучше. Клиенты будут довольны если ее будет много =).