без демона не вариант. придется с каждым вызовом грузить с диска гиг БД. а демон может этот гиг хранить в озу до перезапуска, и соответственно быстрее обработку делать.

без демона не вариант. придется с каждым вызовом грузить с диска гиг БД. а демон может этот гиг хранить в озу до перезапуска, и соответственно быстрее обработку делать.

Ну тогда демон с локальным сокетом, да. Сеть ему не нужна.

что проще - развернуть нттп на си или сокет на пхп?

Очевидно, второе.

спасибо, попробую.

Поставь nginx, а на с напиши fastcgi. И будет тебе счастье

уже стоит, как без этого.

Тогда на кой черт секс с пыхпыхом?

Да, чтобы все понимали, почему именно я говорю, что curl дырявый: https://curl.haxx.se/docs/security.html

Три месяца без CVE — редкая удача.

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

Ну будь готов к тому, что веб на CURL — ад и дырявый израиль. То есть реально безопаснее FCGI сделать, и разве что не руками HTTP хидеры писать.

в хидерах ниче сложного нету, составлял и парсил. я категорически против курла - это чистое зло, он создан для страданий.

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

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

в хидерах ниче сложного нету, составлял и парсил. я категорически против курла - это чистое зло, он создан для страданий.

Это пока на той стороне вебсокеты (протокол поверх HTTP) не сделают. Вот серьезно, я бы на твоем месте хотя бы попробовал Go для сетевой части. Очень может быть, что тебя язык устроит. А вычисления делай на C.

Как МНОГО! КОКИе СЕРЬЁЗНЫЕ CVE ВАУУУ! Да-да, конечно.

Как МНОГО! КОКИе СЕРЬЁЗНЫЕ CVE ВАУУУ! Да-да, конечно.

О, у C-фанатика стадия отрицания.

я категорически против курла - это чистое зло, он создан для страданий.

курл неудобен. но других универсальных и компактных библиотек для работы с вебом просто нет. курл страшен потому что веб страшен :) это не зеркало кривое. это оригинал кривой. нельзя сделать так, чтобы в вебе всё работало и код был простым. ты можешь накостылять что-то для какого-то частного случая. но придумают очередную смену каких-нибудь стандартов веба и твоя фигня перестанет работать. курл написан так, чтобы можно было внедрять любые извращения веба без глобальной переделки кода.

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

Сложный код — хрен с ним. Почему там CVE каждый месяц находят? И зачем там SMTP?

где там «CVE каждый месяц»? у тебя какая-то паранойя насчёт CVE.

Выше ссылка. Почти каждый месяц отмечен новым CVE.

Вот, сюда вставлю: https://curl.haxx.se/docs/security.html

и где там «каждый месяц»? и если ты почитаешь, про что там, то там ничего опасного нет. если код писать аккуратно.

а SMTP - протокол. почему бы его исключать из сетевой библиотеки? даже NTLM, не к ночи будет помянут, тоже протокол. хотя хрен на него и никому он не нужен. но вот даже его проверяют и правят мелкие баги.

и где там «каждый месяц»?

Ну ссылку открой, лол. В феврале три штуки. Потом три месяца перерыв, и пошло-поехало: октябрь, сентябрь, июль, май, март (несколько штук), январь.

и если ты почитаешь, про что там, то там ничего опасного нет. если код писать аккуратно.

Там переполнения буферов, стека и integer overflow (один из самых опасных UB). Это, по-твоему, «ничего опасного»? :)

P.S. В нем еще auth leak недавно нашли, который там чуть ли не с первого коммита был.

и что? несущественные баги в протоколах типа ntlm тебя так пугают? меня они вообще не колышут.

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

и что? несущественные баги в протоколах типа ntlm тебя так пугают? меня они вообще не колышут.

Во-первых, если в библиотеке регулярно находят проблемы с памятью — у нее отвратный Q&A. И еще автор пишет небрежно. Это не внушает доверия.

Во-вторых, куда же подевались твои «хорошие программисты не допускают проблем с памятью»?

В-третьих, баги там везде, не то только в NTLM. Самый эпичный за этот год:

curl might leak authentication data to third parties.

When asked to send custom headers in its HTTP requests, curl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is in particular a problem for applications that pass on custom Authorization: headers, as this header often contains privacy sensitive information or data that could allow others to impersonate the curl-using client's request.

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

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

так что паника, собственно, не к месту.

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

Господи, «дыры — это не дыры, если в моем любимом проекте»? Серьезно? Взрослая же тетя вроде.

взрослая. и ntlm точно не юзаю. вот насрать на него совершенно. а те протоколы, которые используются, быстро тестируются многочисленными юзерами. в этом плюс опенсорца.

я не могу сказать, что я фанат курла. но иногда, когда надо быстро накалякать что-то простое, он удобен.

быстро
баг был с момента первого коммита

Ну лал же.

А, вот смотри еще что в январе нашли:

libcurl contains an out bounds read in code handling HTTP/2 trailers.

It was reported that reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required.

Прочёл комменты.

ТС,Ваша задача по моим ощущениям всё больше напоминает задачку из области IoT. Есть некий сервер, который собирает информацию с клиентов и есть клиенты, которые шлют на сервер свои данные и получают с сервера какой-то результат вычислений, возможно в виде команд. Так?

Т.е., тут что-то типа двунаправленного протокола просится. Но хочется именно http, плюс, в дальнейшем, закрытия канала по ssl/tls, т.е., https?

Из опыта бы рекомендовал либо xmlrpc-c, либо mqtt.

XMLRPC-C. Это на С. http://xmlrpc-c.sourceforge.net/ Транспортный протокол http(s). Сообщения к серверу и от него обёрнуты в XML. Можно написать как standalone сервер, так и CGI-based (в составе идёт сервер abyss, который работает с cgi). Наша задача — обращаемся к https://server:port/method_name с параметрами в запросе, method_name, это метод, реализованный на стороне сервера, генерируется запрос POST, данные транслируютсяна сервер соответстющему приложению (методу, который мы написали), он получив данные, как-то их обрабатывает и возвращает клиенту результат.

MQTT. https://github.com/eclipse/mosquitto Это тоже на С, но здесь надо понимать что есть публикатор данных и подписчик и роли (весьма возможно) придётся менять. Т.е, publisher данные послал, subscriber их принял, посчитал, сам стал publisher, опубликовал... и т.д. и т.п. MQTT, в отличие от xmlrpc, это про пересылку данных и команд, а не про их обработку. Канал через ssl/tls тоже закрывается на счёт «раз», но тут уже не http(s), а свой протокол транспортного уровня. Впрочем, MQTT даже web-sockets поддерживает, так что, возможно я и поспешил. Но я web-sockets в mqtt ни разу не использовал, как оно там врать не буду.

Так-то, я бына xml-rpc остановился бы, если я правильно понимаю задачу.

Про CGI/FastCGI... Это отдельно. Почему я бы сюда не кинулся. Если по сути, то самое простое это cgi. Это некая софтина, запускаемая локально (там же где и web-server) и получающая от сервера через переменные окружения данные и наследующая от сервера stdin, stdout, stderr. Пишут ихи на баше и на С и на перле. На чём угодно. Ногимор в том, что не все сервера поддерживают данную технология в чистом виде. Например, упомянутый nginx поддерживает только scgi или fastcgi. А это несколько иное. Чистые CGI это будьте любезны поставить lighttpd, thttpd или, не к ночи будь помянут, apache. Т.е., накладных расходов больше. В итоге.

FastCGI. Это prersistent web applcations. Работает через сокеты, что позволяет запускать на удалённом хосте и обращаться через https://host:port/file.fcgi[параметры]. Например, можно поставить десяток серваков с nginx, перенаправляя пользюковские запросы на парочку пробкотронов внутри своей сети, где крутится с сотня fastcgiшек, реализующая логику. Но тоже не особо айс. Хотя, и намного лучше чем cgi, т.к. постоянно работают и не перезапускаются как cgiшки при каждом запросе пользюка. Если есть в fastcgi работа с базой, то с cgi можно повесится на логине (а если логин в базу, да ещё и по сети... песня просто). Fastcgi раз залогинился при старте и дальше тупо работает отрабатывая запросы. Т.е., накладных расходов тут меньше.

Вариант с модулем для того же nginx. Т.е., расширить функционал сервера своим модулем. Можно. Горизонтальная масштабируемость тут на высоте. Поставил десяток серваков, под них собрал свои модули, радуйся жизни, пока не пришла пора расширять функционал. Это самый гиморный вид решения, хотя и самый быстрый по идее. Если не брать во внимание mqtt/xmlrpc.

Свой сервак с libevent. Всё хорошо, но клиент надо будет так же свой писать (libcurl в помощь). Тут, кстати, пугают уязвимостями в libcurl, но это как-то пофиг, т.к. будь уязвимости в libevent, я бы очканул, а уязвимости в клиентской либе... Да похрен как-то. Почему именно libevent? Там есть http-parser сразу и есть поддержка ssl/tls. Хотя, она и жирновата, да.

Почему не похапе? Потому что, если вдуматься, то за последние лет 30 пыхеры не удосужились ни фига выродить что по своей сути отличалось бы от cgi/fastcgi, кроме говнины, которая ресурсы жрёт как не в себя.

Ну вот, как-то вот так. Присмотритесь к xml-rpc, короче, и к mqtt.

я не могу сказать, что я фанат курла. но иногда, когда надо быстро накалякать что-то простое, он удобен.

Безусловно. Только вот реализация на Go от таких грехов не страдает. Так почему же не взять хороший инструмент вместо бажного?

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

Только вот реализация на Go от таких грехов не страдает. Так почему же не взять хороший инструмент вместо бажного?

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

И чё?

Уязвимости в пользюковской либе. Ну и заломайте теперь с их помощью сервак, где libcurl может в принципе не быть, а будет например, libevent, на основе которой написаны микросервисы, которые крутятся на данном серваке? Вперёд! =)))

Здесь эти уязвимости что есть, что нет. Ну плохо, да. Но не фатально.

Если бы эти уязвимости были здесь (https://www.cvedetails.com/vulnerability-list/vendor_id-15590/product_id-32303/Libevent-Project-Libevent.html), то я бы да, очканул. А так...

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

Да, чтобы все понимали, почему именно я говорю, что curl дырявый

Список дыр даёт понять: (1) это здоровенный комбайн, (2) его достаточно часто используют, чтобы исследователям было интересно смотреть в кишки. К сожалению, на основе этого списка нельзя понять, меньше ли дыр в других проектах или нет.

Нельзя. Но я не уверен, что libcurl сейчас используется чаще гошного http.

Зачем использовать язык с произвольным доступом к памяти и потенциальными проблемами, с этим связанными, если можно этого не делать? Серьезно, вот хоть один аргумент, влияющий на данный конкретный use-case.

нормально так решений подкинули, спасибо

Честно?

Потому что существуют задачи, где приходится писать например свой менеджер памяти. Или использовать какой-то готовый. Иначе memory fragmentation в демоне, который относится к business critical или mission critical и его безнаказанно не перезагрузишь чтобы очистить ресурсы. Так что, выкусываем из общей памяти какой-то объем и дальше в его пределах выделяем-освобождаем области памяти, не залезая в остальную память.

С другой стороны, сообщество уже придумало инструменты для контроля как динамические, так и статические. Первое это valgrind/mtrace (#nclude <mcheck.h>, выставится хук на malloc()/calloc() и можно будет посмотреть где насрали). Второе это тот же splint. У меня основной редактор это vim, там стоит syntastic и настроен на работу со splint. Как только открываю исходник или записываю, так splint мне показывает в деталях где я дятел. И по работе с памятью тоже. Чего сложного-то? Авторы libcurl для себя не открыли splint? Там документация от 2003г. С тех пор,знаете ли, ни чего нового ни в срыве кучи ни в срыве стека не открыли. =))) Всё одинаково. И вот уже который год. CERT тоже свои рекомендации уже давным-давно выпустил. Нет, всё ходим фигнёй маемся. =)))

Нельзя. Но я не уверен, что libcurl сейчас используется чаще гошного http.

очень смелое заявление.

Да господи иисусе. Мы тут не говорим про ситуацию, когда чувак сидит с кастомными драйверами для ethernet, работающими в userspace, с hugetlb, собственным memory management и nvmeof в четыре pcie слота. У него json через php.

Не вопрос.

Я с этим говном сам работаю (да и с МК и с embedding и с web) в общем и целом. И да, на С. Брат покамест жив.

Я только, если позволите, завтра наверное Вам ещё подкину чего посмотреть по переходу от bare-metal programming к «нормальному линуксовому» на С. Так проще будет, т.к. если в bare-metal С это, по сути, высокоуровневвый ассемблер, то в Линукс это не совсем так. Тут бы лучше например и для начала найти книгу M. Kerrisk. The linux programming interface. Вещь это мастхэвная в том плане,что крайне грамотно распедален API Linux (там только по pthreads двеглавы, ЕМНИП). Вроде, говорят, даже есть русский перевод, но я за него ни чего не скажу, не видел.

Но всё, что мы тут обсуждаем, это всё зиждется именно на API системы, которые описаны у Керриска. Не будете понимать... Рано или поздно с шишками и затрещинами от системы, но придётся это понять.

очень смелое заявление.

Если бы оно было. Я не знаю, нет у меня адекватной статистики.

$ equery depends curl
 * These packages depend on curl:
app-crypt/gnupg-2.2.10 (>=net-misc/curl-7.10)
app-emulation/virtualbox-6.0.4-r1 (net-misc/curl)
app-forensics/afflib-3.7.4 (s3 ? net-misc/curl)
app-i18n/uim-1.8.8 (curl ? net-misc/curl)
app-office/libreoffice-6.1.4.2 (net-misc/curl)
app-text/fbreader-0.99.4-r5 (net-misc/curl)
app-text/mupdf-1.14.0-r2 (curl ? net-misc/curl[static-libs?])
app-text/poppler-0.68.0 (curl ? net-misc/curl)
dev-cpp/libcmis-0.5.2_pre20160820-r1 (net-misc/curl)
dev-db/mysql-5.7.24 (net-misc/curl)
dev-lang/php-7.2.14 (curl ? >=net-misc/curl-7.10.5)
dev-lang/rust-1.32.0 (net-misc/curl[ssl])
dev-util/cmake-3.9.6 (>=net-misc/curl-7.21.5[ssl])
dev-vcs/git-2.19.2 (curl ? net-misc/curl)
games-strategy/freeciv-2.6.0 (net-misc/curl)
media-gfx/exiv2-0.26_p20180811-r3 (webready ? net-misc/curl[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
media-gfx/feh-2.18.3 (curl ? net-misc/curl)
media-gfx/gimp-2.8.22-r1 (curl ? net-misc/curl)
media-libs/raptor-2.0.15-r1 (curl ? net-misc/curl)
net-libs/nodejs-8.12.0 (test ? net-misc/curl)
net-misc/networkmanager-1.14.4 (>=net-misc/curl-7.24)
sys-apps/smartmontools-6.6 (update_drivedb ? net-misc/curl)
sys-fs/cryfs-0.9.9 (net-misc/curl)
www-servers/nginx-1.14.1 (nginx_modules_http_security ? net-misc/curl)

в каком пакете лежит go http я не в курсе и установлен ли он у меня

Ни о чем не говорит, к сожалению. Нужна статистика по работающим code path, а не по опциональным фичам (много людей юзают вон тот модуль NGINX, например?). А гошный http есть в любом докере.

Знаю, что curl в git используется, и вот тут действительно раздолье. Но git и сам с remoteexec справляется.

И как это зависит от языка?

Нет, ну серьёзно? Ну пока у него простая задача, да. А, не дай Бог, произойдёт её усложнение? Ну, например, он увеличит число опрашиваемых устройств? А они по сети работают, в разных сегментах, где разная латентность. Протокол двунаправленный, т.е., данные и с устройства и на устройство. И что делать? Вот мы и подбираемся к ситуации, когда он задумается о своём менеджере памяти.

Почему язык должен кого-либо в чём-то ограничивать? Проблемы с памятью, на мой взгляд, это как дизентирия. Болезнь грязных рук. Сделал malloc()/calloc(), ну так будьте любезны и free() сделать. Выделяете область памяти? Ну так проверьте возвращаемое значение и границы области... Это аксиоматично как сходили в туалет — помойте руки после посещения.=)

Это аксиоматично как сходили в туалет — помойте руки после посещения.=)

до посещения тоже надо

Нет, ну серьёзно? Ну пока у него простая задача, да. А, не дай Бог, произойдёт её усложнение? Ну, например, он увеличит число опрашиваемых устройств? А они по сети работают, в разных сегментах, где разная латентность. Протокол двунаправленный, т.е., данные и с устройства и на устройство. И что делать? Вот мы и подбираемся к ситуации, когда он задумается о своём менеджере памяти.

Крайне, КРАЙНЕ маловероятно. Разве что он данные через infiniband гонять начнет. Но чото я сомневаюсь.

Почему язык должен кого-либо в чём-то ограничивать? Проблемы с памятью, на мой взгляд, это как дизентирия. Болезнь грязных рук. Сделал malloc()/calloc(), ну так будьте любезны и free() сделать. Выделяете область памяти? Ну так проверьте возвращаемое значение и границы области... Это аксиоматично как сходили в туалет — помойте руки после посещения.=)

Зачем плодить attack surface ради мифической возможности заюзать собственный алокатор? Ну не файловую систему он пишет.

Если честно, то я не готов спорить.

И, более того, даже не хочу. =) Просто потому, что давно уже в своём коде научился не косячить. Тут вопрос в квалификации программиста, да. Но для меня, например, С гарантирует что код будет более-менее одинаково работать с минимумом оверхеда на практически любом железе. И на той же Raspberry Pi 2/3 и на дескопе и на сервере. Я не готов спорить просто потому, что я готов к решению задачи практически не задавая вопросов насчёт железа. Особо весело бывает на Orange Pi Zero W, но там мозгов всего 512М, так что с серверами там можно, конечно, но особо не разбежишься. Или на каком-нибудь роутере с 32М мозгов. Тоже бывает, хотя, mosquitto в той же OpenWRT есть и мой код даже работает. Даже там. Хотя, это и просто звиздец, конечно. Не для того оно. Но мне в принципе без разницы. Хочет заказчик, так почему и нет? =))) Он же бабки тратит, а не я.

Мне сидеть и думать над тем, на каком же языке мне вот это вот написать, просто зачастую и некогда. Просто пишем. Просто работает. Косяков, вроде, не наблюдается... А насколько это идеологически верно... Да похрен как-то. Если уж честно, то от стандартной библиотеки рантайма ещё ни кто не убегал. Вот я её и испоьзую без лишних уровней абстракции, привносимых другими языками. Так оно как-то проще получается. =) На мой взгляд.