Решил перед школой программирование поизучать? Doing it wrong

5 секунд в гугле https://github.com/DanielWaterworth/Raphters

Какая школа? Я в детский сад идти собираюсь......

Смехотворно маленькая библиотека, код по пальцам пересчитать можно, может это удобный мелкий API для сетевого функционала,но фреймворком это стыдно называть

Вот стало интересно, для языков типа python,perl,ruby фрейmворков для вэба завались, а есть ли такой фреймворк для старого доброго ассемблера? Для надмножеств он есть к примеру у Objective-C, и я имею ввиду не несуществующий С/С++ с плюсами в каше, а именно для стандартов чистого ассемблера типа x86 с sse? Или z80? Или может даже для i4004?

//фикседъ.

Школотроны разбушевались.

Хорошо, какой профит в веб от этого?

Никакого, просто интересно стало.

Apache

Когда же чёртов учебный год начнётся?

Основные преимущества вышеозначенных языков перед Си для веба в том, что, во-первых, работать со строками в них намного проще и нагляднее, во-вторых, не нужно пересобирать приложение при внесении изменений, в-третьих, динамичность языков предлагает программистам разнообразные фишечки, например, ORM, шаблонизацию и т.п. Да, всё это можно так или иначе реализовать на си, но будет слишком неудобно при работе. Те же ассоциативные массивы вида Map<String, String> (и очень часто значение рассматривается как число) в «веб-языках» применяются достаточно часто, а вот в си и даже в C++ удобно работать с ними имхо проблематично.

Есть такой фреймворк - называется nginx

есть, погугли и найдёшь

только у веб-разработчиков С не является модным, ибо неосиляторы :)

Те же ассоциативные массивы вида Map<String, String> (и очень часто значение рассматривается как число) в «веб-языках» применяются достаточно часто, а вот в си и даже в C++ удобно работать с ними имхо проблематично.

Это чем же std::map и аналоги проблематичные?

Сходу могу назвать одно применение - веб-интерфейсы всяких маршрутизаторов и/или управляемых коммутаторов, чтоб не тянуть реализацию php/perl/lua и т.п. в ограниченную среду прошивки (хотя, сейчас для многих это уже не помеха). В общем, embedded применение.

В интернете есть. Самое основное - это cgi интерфейс для сишечки, остальное уже самому можно накалякать на коленке, там ничего сложного.

Извращенец.

Вот пример нашей консоли сделанной на С+ExtJs на стороне клиента раз и два Никаких cgi, все сделано на модулях nginx

Это чем же std::map и аналоги проблематичные?

Ну вот в том же пхп можно написать так:

// Создаём массив с подмассивами
$a = array(
	'something' => array(
		'first' => 1,
		'second' => 2,
		'third' => 3,
	),
	'other' => array (
		'options' => 'default'
	),
);

// Добавляем ветку 'foo'
$a[] = array(
	'foo' => 'bar'
);

// Удаляем ветку 'other'
unset($a['other']);

В C/C++ это будет не столь наглядно и удобно, по крайней мере, без дополнительных обёрток.

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

в Си нет никакого std:map

Самое основное - это cgi интерфейс для сишечки

есть fast cgi, более эффективный, и даже сишная библиотека к нему, libfcgi кажется

Я в курсе, но как правило любой практикующий сишник пользуется либо своими велосипедами, либо готовыми библиотеками (например libavl) с аналогиченой функциональностью. И для него использование давно обкатанного инструмента мало чем отличается от использования встроенного в язык «типа». Букаф приходится писать больше, тут конечно минус.

Никаких cgi, все сделано на модулях nginx

А у модулей nginx общение с nginx по fastcgi или там свое api ?

Интересный у вас кастомер если решил и оплатил все делать именно так, а не в 100 раз проще с тем же результатом. Эстет

Модули встраиваются прямо в nginx. Т.е. фактически мы, расширяем nginx.

Другой вариант не факт, что обошелся бы дешевле. Нам все равно нужен HTTP интерфейс с большими требованием по производительности (>10 k запросов в секунду), делать его на чем-то другом фактически невозможно. А так мы сделали фреймворк на котором можно очень быстро разрабатывать подобные консоли. Например, чтобы добавить редактирование новой таблицы надо добавить 4 строчки в json файл. Т.е. у нас сделано что-то вроде MS Dynamic Data - форма для редактирования генерится на основе информации из базы данных.

Также в консоли используется уровень DAO, который используется и в других компонентах. Если бы делали не на С, то пришлось бы его писать два раза.

У нас есть еще один тип серверов, который представляет из себя лоадбалансер, который перекидывает запрос на тот кластер, где сейчас находится пользователь к которому относится этот запрос.

Консолью занимается один человек, плюс он занимается и другими задачами.

Нам все равно нужен HTTP интерфейс с большими требованием по производительности (>10 k запросов в секунду)

Так все умеют, учитывая что это HTTP.

Также в консоли используется уровень DAO, который используется и в других компонентах. Если бы делали не на С, то пришлось бы его писать два раза.

Нельзя построить к ним интерфейс?

а если у меня есть уже fastcgi насколько его тяжело переделать в модуль nginx? я к тому насколько отличается там api и каков выигрыш в скорости относительно fastcgi?

Так все умеют, учитывая что это HTTP.

например? php - не сможет работать с такой скоростью и с малым потреблением ресурсов, java - на сервлетах - максимум получалось выжать 14 тысяч в секунду, на nginx такой же запрос давал 160 тысяч. Если делать в более продвинутом варианте, получалось бы сложенее чем на C. Если интересно, могу привести пример кода на С.

Нельзя построить к ним интерфейс?

А зачем? Напрямую работать проще, и достаточно быстро разрабатывается.

Насчет выигрыша не замерял и подсказать не могу, т.к. мы не делали fastcgi. Апи, конечно другой.

KLone

KLone - http://www.koanlogic.com/

что вы можете сказать о KLone в сравнении с модульным расширением nginx?

embedded

RESTful-интерфейс на С + пара статичных html и js.

фреймворк для RESTful на C не знаю, но много кода быть не должно

Я не увидел адекватных тестов производительности Klone. То, что у них на сайте - выглядит ненормально. На мой взгляд, модули nginx выглядят куда лучше. Просто не надо мешать две вещи - отдачу контента в том числе и сгенеренного и его генерацию. С точки зрения отдачи контента - nginx вне конкуренции. А вот прикрутить к нему генерацию контента - особых проблем не вижу. Более того, есть куча модулей всевозможных.

Попробуйте поиграться с extjs на клиенте + генерация json на сервере.

Напрямую работать проще, и достаточно быстро разрабатывается.

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

Klone

Видел я вроде такой, но там была зависимость от драйвера принтера на Руби.

Очень познавательно, спасибо. Судя по реализации, нагрузка действительно аховая.

fastcgi не в каждый роутер запихнёшь. В том же busybox его нет. Да и частенько это лишняя сущность, там нагрузки не требуются по количеству запросов, лишь бы проц/память не грузились левыми абстракциями.

Вон выше вполне приличный вариант предложили - модулями к веб-серверу, вообще убираются пляски с cgi и его переменными окружения, форками отдельных процессов и т.п.

УМВР. Самопальная CGI-библиотечка. Когда-то начал было поддержку вебсокетов добавлять, но что-то "сдулся" (частный случай воткнуть можно, а вот для общего многовато писать надо — с недельку убить!).

вообще убираются пляски с cgi

Вот, можно подумать, что замена CGI на SSI + подмену адресов что-то изменит!

man cgic

А причём тут подмена адресов и ssi?

Осталось каких-то 4ре дня.

А как ты еще сделаешь аналог запросов?

SSI позволяет из статического контента генерить динамику. Подмена адресов позволяет вызывать нужный CGI или модуль сервера для обработки GET/POST-запросов.

Нынче так не модно. динамика генерится уже на клиенте. Подмена адресов вообще не нужна.

динамика генерится уже на клиенте

Сервер же сдохнет 100500 запросов принимать! Проще одним.

И да: все равно, даже если ты будешь на клиенте генерить, тебе придется делать POST-запросы серверу. И как ты их без CGI или подмены адресов обработаешь?

Серверу лучше принять 10 простых, чем 1 один очень сложный. Также это лучше с точки зрения архитектуры приложения. POST запросы обрабатываются без подмены адресов и без CGI. Просто модуль его обрабатывает. Также можно вообще обойтись без POST, а пользоваться только GET. POST необходим только если очень много данных. Например, при загрузке на сервер файлов.

Собственно сервер, скриншоты которого я запостил выше именно так и рабоает.

На консроль - нагрузка небольшая. Но есть куча серверов, которые дергают запросы для получения/обновления информации. В том числе у нас встроен еще и LUA.