Видел только гостевуху на шелле.
А так эмбеддота всякая до сих пор, да.
>Кто-нибуть еще в 2к21 юзает столь хардкорный подход?
Хз. Я в Сишном треде спрашивал про это, но чето никто нормально не пояснил.
Ну полученные +1000% перформанса на деле несколько десятков наносекунд, ну сам код от бытия написанным на С лучше пыхи не становится, ну учитывая велосипедность из лапши ценность становится даже ниже пыхокода, ну затраченные х20 времени в сравнении с пыхой делают ситуацию ещё более жалкой
Иди лучше сделай какой-нибудь плагин к нгинеху или перекатись на го
Как-то в юности пробовал написать на С++ некоторые пхп функции по работе с текстом, у меня оказались они медленнее чем они исполнялись в пхп. Я понял, что нельзя просто взять С++ и сделать быстро (да и всегда есть шанс что прикрутишь какую-то либу и словишь тормоза, потому что она написана под фан очередными попенсорщиками, которые скорее играют в код, чем делают продукт)
Не очень-то хардкорный подход. Эта хуйня не просто так сдохла, и скорость разработки не при чём.
CGI означает, что на каждый http-запрос будет запускаться отдельный процесс, всё инициализировать с нуля, подключаться к БД, генерировать ответ и завершаться. Огромный оверхед, чтобы вывести чуток данных. Придумали давно всякие костыли типа FastCGI, но непонятен их смысл, если достаточно сделать веб-фреймворк для C/C++. И они действительно существуют, кому надо - тот использует. Надо, правда, редко, почти все тормоза вызываются БД, но там ничего не поделать, проблема в медленных жёстких дисках. А вот когда очень много вычислений и обработки данных в ОЗУ без обращения к БД, тогда и есть смысл. В обычном среднесайте такого никогда не встретишь. Во всяких гуглах и фейсбуках - встретишь.
С
П
Ну а если просто написать небольшой C/C++ сервер, который не будет отключаться после каждого запроса и который будет обрабатывать HTTP запросы в отдельных потоках, отвечая соответствующим HTML-ом?
Вопрос чисто теоретического характера, так как ничего подобного я на практике реализовывать не собираюсь.
С нуля реализовывать HTTP-сервер слишком муторно, там куча заголовков, keep-alive, кеширование, SSL и много других проблем. Да и зачем? Куча готовых есть (Treefrog, Drogon, Poco), подключаешь, описываешь контроллеры, вызываешь главную функцию, и вот тебе сервер на C++, который в отличие от всяких питонов-пхп-ruby самодостаточен и не требует ставить всякие апачи.
Гугли хайлоад. Есть соревнования даже по этой теме, типа обработать миллион запросов как можно быстрее. Там делают на крестах.
Я прямо сейчас работаю с cgi на паскале. Это херня из 87 года изначально. Брутальность зашкаливает, гита нет, ИЧСХ - в целом работает неплохо.
Пхп питоны руби тоде не треьуют ставить никаких апачей. Если теья устраивает, что твое прилодение само смотрит мордой в мир, теье не нужны реверс прокси, балансировка и ты не привык разделять ответсивенность в архитектуре, то на здоровье, но ССЗБ.
>>Кто-нибуть еще в 2к21 юзает столь хардкорный подход?
Ну в таком ключе, как ты описал, вряд ли кто то работает. Делал недавно несколько проектов на C++ на таких фреймворках как Wt и drogon. Первый имеет некоторое количество инструментов, позволяющих в некоторой степени обойтись без css и JS, имеет готовые виджеты, имеет встроенный веб сервер и не плохую либу реализующую ORM. Второй фреймворк славен тем, что его встроенный веб сервер рвет к хуям nginx по производительности.
Я игрался с этим, делал что-то уровня гостевухи на си-плюсах, но это в учебном виде, конечно. Я с этого начинал в веб, даже так.
Сейчас что-то плюсах даже делают, какие-то приложения для хайлоад. Веб традиционный наверное совсем не делают, а когда api под json или вебсокеты, то почему нет?
Ничем принципиально от Го и т.п. не отличается.
Естественно никто в классическом CGI делать не делает такие вещи, это конечно глупо по-определению.
>Кто-нибудь застал чистый CGI и веб-проганье на C?
Я BBS-ки и FIDO застал. Все эти голые деды и выебоны в ориджине.
>Я прямо сейчас работаю с cgi на паскале. Это херня из 87 года изначально. Брутальность зашкаливает, гита нет, ИЧСХ - в целом работает неплохо.
Только недавно в дельфи треде обсуждали, что дельфисты даже гит не осилили.
Да это бля не анекдот, это правда.
Во-первых, встраиваемые системы. Когда нужна страничка внутри кофемолки, это проще и дешевле. Я запускал пример сервера на ПЛИС, там вообще все самодельное, и tcp/ip, ethernet.
На esp32 полно таких одностраничных сайтов на питоне и си.
Кроме этого в сообществе около fasm есть примеры и на ассемблере.
Сам сайт
https://fresh.flatassembler.net/index.cgi?page=content/2_download.txt
Описание движка
https://asm32.info/index.cgi?page=content/0_MiniMagAsm/index.txt
На esp32 полно таких одностраничных сайтов на питоне и си.
Кроме этого в сообществе около fasm есть примеры и на ассемблере.
Сам сайт
https://fresh.flatassembler.net/index.cgi?page=content/2_download.txt
Описание движка
https://asm32.info/index.cgi?page=content/0_MiniMagAsm/index.txt
> гита нет
что мешает завести, компьютер не потянет или нейропластичность уже не та?
WebAssembly?
Нет, там нельзя работать с DOM.
BCHS стек же! https://learnbchs.org/
> нейропластичность уже не та
Очевидно это какой блядь компьютер может не потянуть гит никак не могу заставить начальника пересесть на гитхаб.
Ну как, застал...
Пара чуваков на вопрос чем они занимаются, объяснили что фрилансили на Запад и делали интернет-магазины.
Примерно 2000 году это было.
чЧо тебе это знание даст?
Пара чуваков на вопрос чем они занимаются, объяснили что фрилансили на Запад и делали интернет-магазины.
Примерно 2000 году это было.
чЧо тебе это знание даст?
Странно, про parser.ru ещё не написали
Потому что кроме Темы никто им не пользовался. Пара протохипстеров только.
У меня есть знакомый не из РФ, который поддерживает несколько сайтов на этом чуде. Однако сайты на парсере не по теме треда, по теме треда сам парсер. Тема пару лет назад искал разработчика в команду движка.
> это какой блядь компьютер может не потянуть гит
это была щютка
> никак не могу заставить начальника пересесть на гитхаб
рекомендую селфхостед gitea, подымается в касание, впс за пять баксов нормально тянет
>никак не могу заставить начальника пересесть на гитхаб
Пиздося. Гит можно в худшем случае развернуть по ссх. Гитлаб есть в бесплатном едишине.
И я вообще бы съебывал от такого кабанчика, если начальник туп, то своей тупостью он уничтожит любые позитивные потуги
Я по молодости захуячил на сях вебчат. Была эта хуйня где-то в 1998 году. Плюс/минус год. Но проебался в одном месте - базу чата, т.е. последние 50 сообщений, держал в shared memory в своём собственном формате в виде списка. И я тогда очень мало, почти ничего, не знал о многопоточности. В моём городе, с полутора интернетчиками этот чат работал нормально. Но потом я дал сырцы товарищу, у коготорого в городе было много интернет пользователей. И вот тут-то на его сервере список сообщений начал рушиться в памяти. Ну не знал я о необходимости синхронизации данных, иначе бы там же в shared memory положил pthread_mutex. До сих пор стыдно. Теперь-то я Б-г многопоточности и синхронизации. Но тогда репутацию свою значительно подпортил.
На СИ трудно будет найти хостинг, чтобы разрешили на нём запускать сторонний код. А держать сайт у себя - значит испытывать провайдера на прочность.
> хостинг, чтобы разрешили на нём запускать сторонний код
Называется VPS, используется повсеместно. Да и на тот же Heroku можно через Docker.
на чем кроме сях ещё пишут?
На крестах, на жабе, на говне, на лиспах - на чем угодно, короче.
>Кто-нибуть еще в 2к21 юзает столь хардкорный подход?
Да. Совсем недавно костылил конструктор HTTP GET и POST запросов на Си.
ЧТо не так?
Запросы костылить любой сумеет через libcurl, тонны софта до сих пор так и работают. Вопрос опа про написание веб-бэкенда на сях.
>Вопрос опа про написание веб-бэкенда на сях.
JSON и XML наше всё.
Самый простой пример - управляемая розетка, у которой есть веб-морда.
>Эта хуйня не просто так сдохла, и скорость разработки не при чём.
CGI означает, что на каждый http-запрос будет запускаться отдельный процесс, всё инициализировать с нуля,
Двачую этого
Застал, очень давно, что-то сам так писал, начинал с этого, с CGI на плюсах, но чисто для себя. Для дела же использовал PHP на тот момент.
В принципе в древние времена, если надо было CGI делать, то перл использовали.
На плюсах можно веб программировать и сейчас, но выглядит это совсем иначе. Но я это не пробовал.
Лучше XHTML отдавать, кстати
Бамп.
Репорт.
>Кто-нибудь застал чистый CGI и веб-проганье на C?
Да, он вполне жив в эмбедеде и не только.
>Распиливал пришедшие от юзера аргументы из getenv('QUERY_STRING') ?
Yep.
>Что за проекты были так сделаны?
Из крупного - примерно так работает бекенд Zoom'а. Из мелкого - дохулиард внутренних банковских API, в телекоме - всякие DPI конфигураторы.
>Кто-нибуть еще в 2к21 юзает столь хардкорный подход?
Да, во всю. У меня сейчас кодовая база на 20х крестах, но при этом страница статистики генерится просто печатью в шаблон. Финтех, HFT.
А почему не Erlang для этих целей?
Потому что он про отказоустойчивость, а не перформанс.
А в hft усираются вплоть до длинны провода, по которому твоя железка подключена к серверу.
другой анон
бамп.
Хуямп.
>костыли типа FastCGI, но непонятен их смысл, если достаточно сделать веб-фреймворк для C/C++
Смысл в том, чтобы твой вебсервер крутился в отдельном процессе, а твоя бизнес-логика в отдельном. И чтобы когда что-то ёбнется, то ёбнулось локально и не ёбнулось все целиком. Или чтобы ты свое говно мог перезапустить, не тормозя весь вебсервер.
>С нуля реализовывать HTTP-сервер слишком муторно, там куча заголовков, keep-alive, кеширование, SSL и много других проблем.
С нуля написать свой сервер достаточно просто, все заголовки тебя реализовывать никто не заставляет, кип-алив можешь дропать сразу, про кеширование и SSL речи обычно не идет. Живет такое чудо в микроконтроллерах и прочих веб-интерфейсах от кофеварок. Или за nginx, который сам делает SSL и все остальное.
Один из таких примитивных серверов был описан в древнем журнале КСАКЕП в районе 2000 года. Чтобы не парсить /some/rest/params, автор брал хеши от известных значений и просто хардкодил их в коде, никаких strcmp и подобных. Просто, быстро, гениально. От такого у современных смузихлебиков вылезут глаза. А я и не против.
Зачем? Причин может быть масса. Эти ваши Treefrog, Drogon, Poco взлетят на 20кб памяти?
>Гугли хайлоад. Есть соревнования даже по этой теме, типа обработать миллион запросов как можно быстрее. Там делают на крестах.
Какие же это соревнования, если на крестах? Соревнования инвалидов?
Алсо, мечтаю написать свой шаблонизатор на Сишке. Кто со мной?
Есть бакенд, возможно тоже на сишке, который срет, допустим JSON (чтобы не пугать местное быдло всякими страшными protobuf). Срет чистым, рафинированным JSON, без богомерзкого HTML, без стилей, без всего. Если и будет нужна какая-то разметка, то САМОДЕЛЬНАЯ, а не этот пиздец из HTML. Контент, по возможности, вообще не гоняется, а кладется в БД или в ШаредМемори и передается указатель на него. Аналогично и с файлами, если надо высрать картинку - передается указатель на картинку в некотором файловом сторадже (местный быдломодер не понял про что тред и грохнул его), а сам сторадж - что-то больше похожее на контейнер для кеша или репликации. Если контент списочный (как посты на борде), то передается указатель на коллекцию. В общем, надо изобрести максимально легкий, простой, быстрый протокол, который бы мог описать всю выдаваемую страницу.
А дальше вебсервер на сишечке берет такой "выхлоп", парсит его, уже из своих прекомпилированных ресурсов достает шаблон страницы (HTML+CSS+JS), лезет в локальный кеш за уже отрендеренными блоками страницы. Нет блока страницы в кеше? Сам лезет в кеш и базу за данными, сам их темплейтит, кладет в кеш блоков. Быстро-быстро, по возможности без аллокации памяти, собирает страницу и отдает пользователям.
Как альтернатива, при такой схеме можно собрать выхлоп под любой протокол и быстро сделать "сайт" хоть в калограмме, хоть во втентакле, не говоря про всякие мобильные параши.
Есть бакенд, возможно тоже на сишке, который срет, допустим JSON (чтобы не пугать местное быдло всякими страшными protobuf). Срет чистым, рафинированным JSON, без богомерзкого HTML, без стилей, без всего. Если и будет нужна какая-то разметка, то САМОДЕЛЬНАЯ, а не этот пиздец из HTML. Контент, по возможности, вообще не гоняется, а кладется в БД или в ШаредМемори и передается указатель на него. Аналогично и с файлами, если надо высрать картинку - передается указатель на картинку в некотором файловом сторадже (местный быдломодер не понял про что тред и грохнул его), а сам сторадж - что-то больше похожее на контейнер для кеша или репликации. Если контент списочный (как посты на борде), то передается указатель на коллекцию. В общем, надо изобрести максимально легкий, простой, быстрый протокол, который бы мог описать всю выдаваемую страницу.
А дальше вебсервер на сишечке берет такой "выхлоп", парсит его, уже из своих прекомпилированных ресурсов достает шаблон страницы (HTML+CSS+JS), лезет в локальный кеш за уже отрендеренными блоками страницы. Нет блока страницы в кеше? Сам лезет в кеш и базу за данными, сам их темплейтит, кладет в кеш блоков. Быстро-быстро, по возможности без аллокации памяти, собирает страницу и отдает пользователям.
Как альтернатива, при такой схеме можно собрать выхлоп под любой протокол и быстро сделать "сайт" хоть в калограмме, хоть во втентакле, не говоря про всякие мобильные параши.
Алсо, хоть согласно одному из рейтингов я был Expert по сишечке, но я не очень понимаю как писать на ней бизнес-логику. Массивы, хеши и прочие примитивы в Сишечке конечно есть, но пользоваться ими крайне неудобно. Каждый фреймверк (и даже nginx) изобретает свои строки и свои библиотеки для работы с ними. А перегрузки операторов в Сишечке нету. Короч, все жутко неудобно. Может быть как-то на препроцессоре можно сделать магию, чтобы можно было просто писать, в стиле быдла на быдлоJS? А то как-то обидно, то что у них пишется в 5 строк, у меня пишется в 5 экранов.
Лол, ровно так же делал. Только я начала переписывать некоторые php функции для Си. И там моментом оказалось, что на пхп они быстрее или вровень (чуть медленнее), для меня тоже тогда было уроком, что нельзя было просто взять Си и получить сразу преимущество в производительности (про всякие ключи компиляции я знал, просто сразу попал на какие-то сверх оптимизированные алгоритмы).
Полез тогда в сорцы пхп, чтобы посмотреть как там сделано, но в итоге офигел и забил, ибо понял что нет у меня столько мозгов в этой области.
Учитывая то, кто делал Пехапе потом, там все дичайше заоптимизировано. Но это не значит, что нельзя сделать лучше, надо просто подняться на уровень выше и целиком, весь модуль переписать на Сишечке. Если не поможет - еще выше.
К вопросу "нахуя". Вот как я вижу вебсервер:
Слушает порт, принимает или не принимает соединения
При приеме соединения, пишет в лог IP и время, назначает ConnectionID/SocketID.
При приеме заголовков, пишет еще лог gateway-request (socket id, user agent, lang, other headers).
После приема заголовков, IP/user-agent/URI ресолвится по блеклистам, включаются переменные.
При наличии Cookie, поднимается сессия, проверяется IP+User-Agent и включаются переменные из нее.
При приеме всего тела запроса, пишет лог app-request (поля зависят от приложения), сохраняются файлы на диске.
Если принимаем файл, то регулярно обновляем данные в базе по мере загрузки, чтобы можно было считать часть файла или получить прогресс загрузки.
TODO: подумать о формате статы
TODO: подумать о автоматической конверсии картинок в превьюшки
TODO: подумать о пермутации полей форм для защиты от роботов
При переходе в режим websockets/pipeline, app-request пишется для всех последующих сообщений. Могут выставляться новые переменные в сессию.
Если внутри запроса был передан некорректный form token или некорректная капча, сервер суспендит запрос (уже сохраненный на диске) и отвечает заглушкой, где должен перегенерироваться form token или пользователь должен ввести капчу.
Если количество запросов превышает limit-rate10, то добавляем IP в captha-need базу (выставляем переменную)
Если количество запросов превышает limit-rate100, то добавляем IP в drop-connection базу (сразу закрываем соединение, минибан на 10 минут)
Если количество ошибок более 10, то выдаем бан на 10 минут.
Если нашли в URI потенциально-вредоносную строчку (DROP TABLE, ../ и т.д.), то заносим IP в weird-mode, просим капчу в течении суток на каждый запрос.
Покажите мне готовый сервер, где есть хотя бы часть этого. И да, все это должно быть прямо в сервере, чтобы в случае проблем ДАЖЕ НЕ ТРОГАТЬ бизнес-приложение.
Слушает порт, принимает или не принимает соединения
При приеме соединения, пишет в лог IP и время, назначает ConnectionID/SocketID.
При приеме заголовков, пишет еще лог gateway-request (socket id, user agent, lang, other headers).
После приема заголовков, IP/user-agent/URI ресолвится по блеклистам, включаются переменные.
При наличии Cookie, поднимается сессия, проверяется IP+User-Agent и включаются переменные из нее.
При приеме всего тела запроса, пишет лог app-request (поля зависят от приложения), сохраняются файлы на диске.
Если принимаем файл, то регулярно обновляем данные в базе по мере загрузки, чтобы можно было считать часть файла или получить прогресс загрузки.
TODO: подумать о формате статы
TODO: подумать о автоматической конверсии картинок в превьюшки
TODO: подумать о пермутации полей форм для защиты от роботов
При переходе в режим websockets/pipeline, app-request пишется для всех последующих сообщений. Могут выставляться новые переменные в сессию.
Если внутри запроса был передан некорректный form token или некорректная капча, сервер суспендит запрос (уже сохраненный на диске) и отвечает заглушкой, где должен перегенерироваться form token или пользователь должен ввести капчу.
Если количество запросов превышает limit-rate10, то добавляем IP в captha-need базу (выставляем переменную)
Если количество запросов превышает limit-rate100, то добавляем IP в drop-connection базу (сразу закрываем соединение, минибан на 10 минут)
Если количество ошибок более 10, то выдаем бан на 10 минут.
Если нашли в URI потенциально-вредоносную строчку (DROP TABLE, ../ и т.д.), то заносим IP в weird-mode, просим капчу в течении суток на каждый запрос.
Покажите мне готовый сервер, где есть хотя бы часть этого. И да, все это должно быть прямо в сервере, чтобы в случае проблем ДАЖЕ НЕ ТРОГАТЬ бизнес-приложение.
Хуита, посмотри на код haproxy - оно с таким заморачиваться не будет
О, даже не придётся создавать тему. Как раз то, о чём хотел поговорить...
Подскажите пожалуйста, что за пидорасы разрабатывали вот это:
> Content-Type: multipart/form-data;
Это пиздец гной вместо мозгов у того, кто это придумал. И это легко доказать. Вы пробовали это парсить? А в маленкьом буфере, который заведомо меньше присылаемых данных. А если файлов несколько? Да вы охуетее это парсить на стороне сервера. Вот приходит вам такая беда:
> -----------------------------735323031399963166993862150
> Content-Disposition: form-data; name="file3"; filename="binary"
> Content-Type: application/octet-stream
Рваная, причём, беда - половина signature в прошлом recv, а вторая половина в следующем. И пиздец мозгам.
Конечно можно заранее выделить память размером, полученным из поля Content-Length: HTTP реквеста, но вы охуеете, если пользовали будут слать серверу большие файлы - под нагрузкой ваш сервер просто ляжет.
Внатуре и воистину - протокол multipart/form-data разрабатывали наркоманы в терминальной стадии алкоголизма. А ведь эта мразь могла бы добавить размер файла в параметр Content-Disposition:. И тогда остались бы человеками.
Подскажите пожалуйста, что за пидорасы разрабатывали вот это:
> Content-Type: multipart/form-data;
Это пиздец гной вместо мозгов у того, кто это придумал. И это легко доказать. Вы пробовали это парсить? А в маленкьом буфере, который заведомо меньше присылаемых данных. А если файлов несколько? Да вы охуетее это парсить на стороне сервера. Вот приходит вам такая беда:
> -----------------------------735323031399963166993862150
> Content-Disposition: form-data; name="file3"; filename="binary"
> Content-Type: application/octet-stream
Рваная, причём, беда - половина signature в прошлом recv, а вторая половина в следующем. И пиздец мозгам.
Конечно можно заранее выделить память размером, полученным из поля Content-Length: HTTP реквеста, но вы охуеете, если пользовали будут слать серверу большие файлы - под нагрузкой ваш сервер просто ляжет.
Внатуре и воистину - протокол multipart/form-data разрабатывали наркоманы в терминальной стадии алкоголизма. А ведь эта мразь могла бы добавить размер файла в параметр Content-Disposition:. И тогда остались бы человеками.
> Вы пробовали это парсить?
Парсится элементарно стейт-машиной, держи игрушечный пример: https://github.com/iafonov/multipart-parser-c Но вообще я советую не страдать хуйней и взять проверенный временем парсер-генератор.
Спасибо, приятель. К сожалению я болен NIH-синдромом и попробую реализовать сам, всё же не мальчик и задача мне понравилась своей сложностью. Не согласен, что это элементарно, скорее признаю что Igor Afonov крут. Не скажу, что сделаю оптимальнее, чем Афонов, но таки люблю задачи, над которыми надо поломать голову. И это не отменяет факт что этот протокол придумывали явно душевно-больные люди, потому что не додумались указать размер секции. Явно же разбор был бы проще.
>Это пиздец гной вместо мозгов у того, кто это придумал.
>К сожалению я болен
Don't you know what the "NIH-syndrome" is?
Кстати, почти сделал разбор, осталось финальные -- распарсить.
Без конечного автомата не обошлось. Поля ввода загоняю в строки,
а файлы сразу пишу на диск. А на выходе список структур, в которых описано чего там прислал пользователь.
Так как трэд с сями мертв спрошу тут . Нужно результат выполнения левой проги (допустим ls) реализованный через семейство функций exec вывести не только на терминал но и в файл. Как бы я не ебался побитовое или | не воспринимается функцией как аргумент . Допустим пример ....
Execlp("ls","ls","-l","/var", "|" , "tee", " /path/path/biba.txt", NULL);
Либо так
Execlp("ls","ls","-l","/var", ">>" , "tee", " /path/path/biba.txt", NULL);
Побитовые операторы вообще никак не хотят через нее работать .
Кажись я допер , exec не может использовать две разных проги за раз . Но как тогда вывести в файл . Можно конечно написать свою lsку но если допустим мне нужна не она. Что тогда делать ?
> Так как трэд с сями мертв
Спрашивать надо в C++-треде. Разница только в синтаксисе языков, POSIX API везде одинаков.
Обязательно exec? popen не пойдёт?
Хмм , слушай может и подойдёт . Попробую , потом отпишу.
>Execlp("ls","ls","-l","/var", ">>" , "tee", " /path/path/biba.txt", NULL);
Фикс
Execlp("ls","ls","-l","/var", ">>" , " /path/path/biba.txt", NULL);
именно так : printf("Content-type: text/html\n\n");
Распиливал пришедшие от юзера аргументы из getenv('QUERY_STRING') ?
Что за проекты были так сделаны?Какие-нибудь древние интернет банки,системы учета трафика для провайдеров?
Поскольку форумы и гостевухи были на перл даже в глубокой древвности...
Кто-нибуть еще в 2к21 юзает столь хардкорный подход?