Документация по libfcgi

заголовочного файла более чем достаточно. Луше использовать только функции с «_r» на конце. У них синтаксис вызова почице

Еще можно скачать исходники и ознакомиться с папкой examples. В частности с файлом, в названии которого есть слово «thread»

Вот как. Благодарю. Пойду курить заголовки/смотреть примеры.

С исходниками ещё кстати и документация поставляется.

А зачем тебе FastCGI?

А разве сеть альтернативы?

А разве сеть альтернативы?

Ну да, HTTP.

Ааа... так ты просто не в курсе что такое fcgi и что такое http.

// ЗЫЖ Я уж надеялся что ты предложишь альтернативу получше.

Ааа... так ты просто не в курсе что такое fcgi и что такое http.

В курсе. Поэтому и удивляюсь, зачем нужен FastCGI, когда есть HTTP и WebSockets и соответствующие либы.

// ЗЫЖ Я уж надеялся что ты предложишь альтернативу получше.

Надеюсь, что поймёшь.

HTTP

Тут два сценария: 1 - с web-сервером на фронтенде. 2 - напрямую.

В первом случае в либе придется реализовать отдачу статики, аутентификацию, https и еще много-много чего. Работать оно будет хуже заточенного для таких задач nginx'а

Во втором случае от либы требуется только HTTP/1.0. Но даже его парсер проигрывает по всем фронтам uwsgi или SCGI. И простенькую либу еще попробуй найди. Каждый разработчик норовит встроить ssl вебсокеты, digest auth и прочую срань

uwsgi

И простенькую либу еще попробуй найди.

На самом деле они есть, например, http-parser, picohttpparser

Это только парсер. А возню с сокетами и буферами самому писать?

Так это уже нужна либа для TCP, а не HTTP

Работать оно будет хуже заточенного для таких задач nginx'а

Так почему же тогда вместо того, чтобы писать модуль для nginx'а, который и реализует HTTP, писать FastCGI приложение? Чтобы потом перенести его на Apache, в случае если nginx перестанет справляться с нагрузкой? Ну ты понял, в общем. Лол.

Во втором случае от либы требуется только HTTP/1.0. Но даже его парсер проигрывает по всем фронтам uwsgi или SCGI. И простенькую либу еще попробуй найди.

Чем libwebsockets не устраивает? Или websocketpp?

Я к тому, что в fcgi, uwsgi, scgi-c функция сервера уже встроенна. А http-parser придется руками спаривать с «либой для TCP»

Так почему же тогда вместо того, чтобы писать модуль для nginx'а, который и реализует HTTP, писать FastCGI приложение?

Флаг вам в руки. 1) это трудно сделать; 2) это трудно сделать так, чтобы не угробить при этом характеристики nginx; 3) система с отдельными процессами надженее и гибче (например, во многих задачах для внутреннего сервера-приложения лучше подходит префорк-модель, а для еврес-прокси, торчащего в инет, event-based обычно лучше

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

Флаг вам в руки.

Спасибо.

1) это трудно сделать;

Ну, кому как.

2) это трудно сделать так, чтобы не угробить при этом характеристики nginx;

Ну, тоже самое можно сказать про что угодно, особенно про ту же Node.js.

3) система с отдельными процессами надженее и гибче

Ну так а что мешает запустить несколько процессов NGINX (один на ядро) и форкать/создавать трэды/регистрировать события для разных задач из этих процессов NGINX?

торчащего в инет, event-based обычно лучше

Кстати, libevent идёт в комплекте с простеньким HTTP (а не FastCGI) -сервером.

Чем libwebsockets не устраивает?

Вебсокет это только передача raw-сообщений. Надо что-то еще поверх, причем на обоих концах. Есть что посоветовать? Кроме socket.io ничего в голову не приходит

Так почему же тогда вместо того, чтобы писать модуль для nginx'а, который и реализует HTTP..

Грузить в адресное пространство nginx'а PHP/jvm-машину (или на чем там сейчас пишут сервисы) не лучшая идея. Вот бы nginx предоставил простенький протокол для межпроцессного взаимодействия.. Wait, oh shi~

Вебсокет это только передача raw-сообщений.

Я про libwebsockets: «Libwebsockets is a lightweight pure C library built to use minimal CPU and memory resources, and provide fast throughput in both directions as client or server.»

Надо что-то еще поверх, причем на обоих концах. Есть что посоветовать?

Поясни, что такое «поверх»?

Грузить в адресное пространство nginx'а PHP/jvm-машину (или на чем там сейчас пишут сервисы) не лучшая идея.

Так а кто говорит, что это надо делать? Я говорю про C, а не про PHP/Java. А так, FastCGI, - это да, для всяких интерпретаторов типа PHP.

Ну, тоже самое можно сказать про что угодно, особенно про ту же Node.js.

Поставь свою поделку за реверс-прокси и твори там что хочешь. Только сам реверс-прокси не трожь

Поставь свою поделку за реверс-прокси и твори там что хочешь. Только сам реверс-прокси не трожь

Хочу, чтобы поделка на Node.js могла не отказать не более чем N одновременным запросам. Без коллбэкщины этого сделать не получится, так что подход придётся соблюдать и реверс-прокси не спасёт.

Скажем, решил ты отказаться от б-гомерзкого HTTP в пользу вебсокетов. Понадобилось послать немного JSON'a из браузера на сервер и получить немного JSON-a в ответ. Как ты это будешь делать на чистых вебсокетах? Интересует непосредственно момент передачи запроса и приема ответа

Скажем, решил ты отказаться от б-гомерзкого HTTP в пользу вебсокетов.

Не надо мечтать. HTTP используется для доставки Js в браузер.

Понадобилось послать немного JSON'a из браузера на сервер и получить немного JSON-a в ответ. Как ты это будешь делать на чистых вебсокетах?

После того, как Js завертелся в браузере - тривиально.

Интересует непосредственно момент передачи запроса и приема ответа

А что там интересного?

Я бы посоветовал libmicrohttpd или scgi на коленке.

Не надо мечтать. HTTP используется для доставки Js в браузер.

А ws для чего используется?

А что там интересного?

Отправил запрос по websocket. Как получить ответ?

А ws для чего используется?

Для двунаправленного асинхронного обмена данными. Только сначала надо открыть ws-соединение, а в web это делается только с помощью Js кода, который доставляется сначала по HTTP. Или ты свой браузер писать собрался?

Отправил запрос по websocket. Как получить ответ?

Получить - не проблема. Проблема - обработать :-)

Получить - не проблема. Проблема - обработать :-)

Что верно - то верно)

Впрочем, свой костыль с подпиской на messageid написать нетрудно. Но это будет сугубо твой, нестандартный костыль в самой публичной части приложения - в его API