LINUX.ORG.RU

Вот эту, если буст не strashen - https://github.com/splunk/pion

У нее еще был С++11 форк, в мэйлисте объявляли, нет ссылки под rukoi.

*Сорри за транслит, нету русских буков в раскладке.

anonymous
()
Ответ на: комментарий от eao197

cpp-netlib в вечной альфе же, а POCO - помойка жаваобразная, умеет все на свете, но все кое-как. Т.е. если все приложение на POCO/macchina - то ок конечно, а только ради HTTP сервера я с POCO не стал бы связываться.

anonymous
()
Ответ на: комментарий от hobbit

Проиграл с первого ответа в той теме, а дальше там содержательное обсуждение модулей nginx vs WSDL. Вообщем как-раз опу - то что ЛОР прописал.

anonymous
()

Недавно же тема была аналогичная, но про С. Ну и для С++ ес-но подходит все то же.

anonymous
()
Ответ на: комментарий от anonymous

Ноуп, не подходит, на С можно взять civetweb или libevent. А на крестах делать что-то с сетью и не использовать ASIO (с Boost или без - c C++11-only) - это зашквар.

anonymous
()
Ответ на: комментарий от anatoly

Ну так вопрос какую HTTP библиотеку с ним использовать, руками на ASIO только HTTP 1.0 можно сделать, HTTP 1.1 (а под HTTP именно он понимается) - не получится за неделю-две наваять. HTTPS опять же.

anonymous
()
Ответ на: комментарий от anonymous

civetweb

Так это тот же mongoose, зачем брать лишнее.

libevent

Ну хоть не <sys/socket.h>

А на крестах делать что-то с сетью и не использовать ASIO (с Boost или без - c C++11-only) - это зашквар.

На крестах вполне себе юзабелен тот же mongoose.

anonymous
()
Ответ на: комментарий от anonymous

civetweb

Так это тот же mongoose, зачем брать лишнее.

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

libevent

Ну хоть не <sys/socket.h>

? https://github.com/ellzey/libevhtp , лично знаю большие проекты где это юзается для HTTP сервисов (внутренних).

А на крестах делать что-то с сетью и не использовать ASIO (с Boost или без - c C++11-only) - это зашквар.

На крестах вполне себе юзабелен тот же mongoose.

А еще наверное крестовую программку можно из томката через Runtime.exec() дергать, тоже юзабельно будет.

anonymous
()
Ответ на: комментарий от anonymous

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

Авторы мангуста по сути просто решили сделать свою библиотеку платной. Это нормально, и они имеют на это право. Ну а GPL оставили, чтоб фанатики опенсорса не заклевали, плюс можно патчи принимать, что тоже хорошо.

? https://github.com/ellzey/libevhtp , лично знаю большие проекты где это юзается для HTTP сервисов (внутренних).

Ну это уже как раз отдельная реализация поверх. Ее и стоило сразу назвать.

А еще наверное крестовую программку можно из томката через Runtime.exec() дергать, тоже юзабельно будет.

Если mongoose юзабелен с С, то с С++ он не станет менее юзабельным.

anonymous
()

если знаете С++ то что мешает запилить свою реализацию http сервера? а если не знаете С++ то никакая либа вам не поможет

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Переводя на русский - mongoose теперь называется civetweb, а его жадный автор может продавать что захочет.

И ASIO портабельный же и на многих платформах объезженный . Ну если я например захочу https://github.com/splunk/pion подебажить, то внутри будут общепринятые shared_ptr и socket.async_write. А внутри мангуста будут кишки платформенного сетевого стека, причем без смарт-поинтеров RAII. Я не хочу такое дебажить.

anonymous
()
Ответ на: комментарий от anonymous

Ога, большой и сложный протокол, сравни с FTP например. И проблема в том, что то что ты вывешиваешь по HTTP должно работать из cURL'a/браузера, иначе не кошерно. клиенты не будут под твою ковбойскую реализацию подстраиваться.

anonymous
()
Ответ на: комментарий от anonymous

h323, sip, rtsp, rtp, skype, - так вот http среди них, самый банальный, и написать http сервер кторый отдает какие то html файлы, или стримит контент, и это будет понимать curl или wget и остальные клиенты - это самая банальная задача. либо на лоре тусуются одни школьники, либо меня тролят. надеюсь последнее

anonymous
()
Ответ на: комментарий от anonymous

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

Игорь Сысоев, залогиньтесь, мы никому не скажем что но самом деле HTTP-server это банальная задача, а вы nginx написали за неделю и уже 13 лет тупо пилите бабло инвесторов.

Алсо вопрос с задней парты: уважаемый гасконец, а отчего ваш HTTP-сервер но мои запрос вида:

curl http://127.0.0.1:6666/one_thousand_devils --data-binary @path/to/oche_bolshoi_fail

возвращает ответ:

400: дурной запрос, каналья!!!

И еще, как вы относитесь к multipart контенту, если он chunked?

anonymous
()
Ответ на: комментарий от vzzo

Хотя я ещё в прошлом треде говорил, что лучше навелосипедить wsgi-сервер через тот же asio и проксироваться на него через nginx.

vzzo ★★★
()
Ответ на: комментарий от anonymous

а дальше там содержательное обсуждение модулей nginx vs WSDL

Вообще, сделавшие это на модулях nginx мне понравились.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Я думаю, что упаковка всего приложения в виде модуля nginx - будет наилучшим решением с точки зрения HTTP. Сделать производительность выше чем так, скорее всего вообще невозможно. Только вот с точки зрения C++ и бизнес-приложения на нем написанного это вряд ли будет удобным. Цель обычно - пару сервисов (не всегда первостепенных, мониторинг какой-нибудь или интеграция) вывесить наружу. А не менять для этого все приложение. Ну и API у nginx, как и любое high-performance API, - весьма черезжопное.

anonymous
()

pion, cpp-netlib не работает с С++11
poco - framework

не пишу сам - потому что долго
производительность не нужна.
Спасибо за ответы.

kasha
() автор топика
Ответ на: комментарий от anonymous

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

А стоит за производительностью гнаться? Простенький вебсервер поверх boost.asio даёт на коротких запросах где-то 24 kRPS, тогда как nginx выжимает 25-27 kRPS.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Простенький вебсервер поверх boost.asio даёт на коротких запросах где-то 24 kRPS

А нельзя ли ознакомиться с кодом простенького вебсервера поверх boost.asio, если не жалко, и если он не под NDA? Спасибо.

anonymous
()
Ответ на: комментарий от anonymous

Ага, как же, дает

У меня был однопоточный сервер, так что в нём нет явных блокировок. Указанной скорости он достигал, только если клиент использует keep-alive. Если закрывать соединения, получается где-то 3 kRPS.

Здесь видимо вы что-то свое понимаете под словом «простенький».

Принимает соединение, парсит заголовок, из которого достаёт только URL и Content-Length, читает тело, вызывает обработчик тела, отсылает ответ.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

А что за парсилка хедеров была, если не секрет? Рукописная специализированная (вытаскивающая вручную только-то что нужно), или готовая какая-нибудь?

anonymous
()
Ответ на: комментарий от anonymous

Ага, как же, дает (а потом догоняет и еще наподдает) - http://stackoverflow.com/q/18506739/314015

Прохладная история, я когда-то писал свою библиотеку на C++ для http, достал ее их архива, взял свой же пример, специально отключил keep-alive и получил:

~$ ab -n 10000 -c 100 "http://127.0.0.1:8080/"
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        26406 bytes

Concurrency Level:      100
Time taken for tests:   0.470 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      264660000 bytes
HTML transferred:       264060000 bytes
Requests per second:    21268.36 [#/sec] (mean)
Time per request:       4.702 [ms] (mean)
Time per request:       0.047 [ms] (mean, across all concurrent requests)
Transfer rate:          549695.72 [Kbytes/sec] received

По 127.0.0.1 лежит вот это:

http://i.piccy.info/i9/8e355d4861f56d020a086d9bc31cae5f/1447849383/214875/958...

Пример в собранном виде занимает 60Кб без дополнительных зависимостей. Исходного кода 140 Кб, но там и ручная реализация deflate, и логи, и кэш и пр. Так что не надо пугать людей, сделать простой http сервер под специфичную задачу не так сложно и долго. Понятно, что он будет гораздо примитивнее nginx и пр., но свою задачу решать он будет.

anonymous
()
Ответ на: комментарий от anonymous

Сам написал, на Ragel. В колбеке, который вызывается по окончании значения поля, просто проверяется, является ли имя поля content-length или connection. Остальные заголовки для задачи не были нужны.

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

Кстати, раз уж mangoose по сути «кончился», то если будет время - как-нибудь оформлю эту библиотеку и выложу на github. Там как раз С++11, а точнее C++0x, то, что умели vs2010/gcc на то время.

anonymous
()
Ответ на: комментарий от Deleted

Да, но это ещё и протокол, при чём очень простой.

vzzo ★★★
()

еще есть Wt, webtoolkit.eu

пишете примерно как на Qt.

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

anonymous
()
Ответ на: комментарий от anonymous

rtp

Куда проще http.

sip, rtsp

http-подобные же, http не банальнее их.

anonymous
()

Для разбора HTTP можно взять http-parser. Сетью рулить через asio, ну или libevent, если собственно C++ не так интересен.

const86 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.