Пишу небольшой HTTP сервер, писал интерфейс на MFC, стоит ли писать серверную часть тоже на MFC?
или все же лучше использовать boost::asio или чистые сокеты?

сам только что закончил писать HTTP сервер. По моему лучше чистых сокетов ничего не существует. Стивенс вам в помощь.  

igsilya, не очень хочется заморачиваться потоками вручную )

будет ли это правильным решением - объект-поток создается с помошъю new, при завершении работы потока убивать этот объект с помошъю auto_ptr который указывает на this?

зачем писать?
тут 4 штуки уже написанных  

Добавлено через 6 минут и 26 секунд

по потоку на клиента?  

ну вообще-то так обычно и делают. Еще раз говорю: почитайте "Стивенс У. Р. -разработка сетевых приложений."

я наверное не те книжки читал 


эту книжку не читал. но по потоку на клиента - тупиковая архитектура.

boostcoder, можете документацию какую предложить? интересен сам подход к проектированию сервера.

обычные архитектуры: 1)пул потоков, 2)сопрограммы.

Добавлено через 1 минуту и 38 секунд

подход и архитектура формируются на основании требований. у вас их не видно.

Добавлено через 10 минут и 37 секунд
еще вариант - использовать libevent, если boost сложен. там есть возможность просто создать http сервер.
http://monkey.org/~provos/libevent/doxygen-1.4.10/index.html
http://monkey.org/~provos/libevent/doxygen.../evhttp_8h.html

Добавлено через 11 минут и 12 секунд
и вот: http://incpp.blogspot.com/2009/05/http-libevent.html

и вы хотите сказать, что в пуле потоков не по потоку на клиента?
или тогда поясните что именно вы имели ввиду под сочетанием "по потоку на клиента".

естественно нет.

Это сообщение отредактировал(а) boostcoder - 24.5.2011, 21:22

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

долго объяснять.
в двух словах: неблокирующие сокеты и операции с ними в виде задач. т.е. к примеру, чтение из сокета в терминах asio - это задача. формирует задачу и управляет ею asio::io_service.
в общем доку читайте: "The Proactor Design Pattern: Concurrency Without Threads"

Это сообщение отредактировал(а) boostcoder - 24.5.2011, 21:38

> Пишу небольшой HTTP сервер, писал интерфейс на MFC
Объясните несведущему в серверостроении - как у http-сервера м.б. интерфейс?

А по вопросу - нет. Не стОит, потому, что MFC - труп, даже не ходячий, а еле ползающий. См. в сторону boost или Qt

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

Я вот тут подумал, м.б. автор хотел сказать
Пишу небольшой HTTP сервер. До этого писал только интерфейс и только на MFC
???
тогда понятно.

Это сообщение отредактировал(а) borisbn - 24.5.2011, 22:16

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

ну так не архитектуру "клиент = поток". хотя исходников апача не видел. но тупиковость архитектуры очевидна. вряд-ли они такое гэ закодили.

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

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

здесь как раз 1 поток = 1  запрос.

или я чего-то не понимаю?

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

В общем это задание, нужно было написать прогу типа прокси, у нее есть интерфейс на мфк который показывает лог. Загвоздка была в том что я с мфк знаком был только отдаленно, но все же интерфейс добил. Остался сам прокси, парадокс в том что я с интернет трафиком знаком очень близко - писал снифферы/грабберы, протоколы понимаю нормально, но вот с сокетами редко связывался - и то для отправки файлов или каких-то пингов.
Прокси уже пишу на мфк так как нашел вроде нормальные примеры. Мне тоже непонятна идея с пулом потоков если каждый запрос обрабатывается не отдельным потоком.

запрещено использовать что-либо кроме мфк, стл и буста.

Это сообщение отредактировал(а) asmdzen - 24.5.2011, 23:00

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

boostcoder, получается значит не совсем асинхронно, ведь если на все потоки пула придет по команде типа Receive то они все зависнут на время, не так?

igsilya, asmdzen, касательно пула потоков и asio - вы все неверное понимаете. очень рекомендую читать доку с самого начала и до конца.
пул потоков в asio используется только для обработки задач io_service`ом. в коде, при работе с сокетами, не нужно знать о том что используется пул потоков. io_service сам распределяет задачи(в данном случае задачи для работы с сокетами) между потоками пула.

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

Добавлено через 5 минут и 25 секунд

так основное время работы сервера как раз и занимают операции ввода-вывода(http сервер по сути больше ничего делать и не должен) 



=> весь сервер исходя из ваших слов т.е. его I/O часть работает как раз по принципу , похожему на тот который я описал.

не совсем. тут еще важно понимать, что разные задачи реализованы по разному.
к примеру задачи чтения/записи из/в сокет, в недрах asio, разбиваются на подзадачи. т.е. из сокета в один момент времени читается столько байт, сколько можно прочесть без блокировки. т.е. если вы выполнили async_read() для 1024 байт а для чтения доступно только 32 - то прочтется только 32. остальные прочтутся когда будут доступны. таким образом, задачи чтения/записи делятся на подзадачи. не явно. но задача полностью завершится тогда, когда сумма прочитанных байт всеми подзадачами будет равна 1024.

boostcoder, спасибо за объяснение, просто при просмотре примеров на бусте волосы дыбом встают - много новых элементов, например я никогда не использовал boost::bind, а он там постоянно мелькает )
потом надо будет объяснять что это делает в моем коде )
насколько я понял boost::asio и есть самый выгодный вариант (особенно если он сам работает с пулом )

я говорю об asio. на протяжении всей дискуссии.


от части. но очень отдаленно.

Добавлено @ 23:15
asmdzen, кстати http-proxy: http://alexott.net/ru/cpp/BoostAsioProxy.html
и еще, на libevent: http://monkey.org/~marius/pages/?page=nylon


Это сообщение отредактировал(а) boostcoder - 24.5.2011, 23:18

получается, что вы назвали "тупиковой" дну из основных составляющих  того что так усердно расхваливаете. Не противоречите ли вы сами себе?

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

придется наверное все-таки писать под бустом, с мфк не канает что-то, поставил Sleep(10000) при Receive и засыпает вся прога - а я думал у них какие-то потоки есть (

"Не читал, но осуждаю" ©

Рекомендую серьезно ознакомиться с Asio. Возможно, после этого взгляд на мир будет совсем иной. А для затравки скажу: у меня однопоточный сервер (что-то типа SSL прокси и без пула потоков) может обрабатывать тысячи одновременных подключений (т.е. я проводил стресс тестирование, но обычная нагрузка порядка нескольких десятков-сотни). Причем, сильно нагруженных. Написан с использованием boost::asio.

Добавлено через 1 минуту и 3 секунды
asmdzen, тебе сказали, MFC давно труп. Использование его стоит свести к минимуму.

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

читайте с начала.


голословное утверждение.


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

Добавлено через 1 минуту и 12 секунд

в третий раз вы все неправильно поняли.

Вот тут непонятно.
Если в программе один поток, то подключения обрабатываются последовательно. Нет ?
Если же распараллеливание берёт на себя asio, то сервер, всё-таки, не однопоточный.
Или же, если под "обработкой" считать то, что запрос принят, и обработка (подготовка ответа и выдача его клиенту) поставлена в очередь, то, наверное, можно сказать, что подключения обрабатываюся одновременно.
Растолкуйте, где я не прав, пожалуйста.

я так понял, что речь о приеме подключений. если да - то принятие подключения(accept) выполняется поочередно.


не понятно, откуда взято мнение о том, что asio создает какие-то потоки?! никаких потоков для эмитации асинхронности asio не создает!
единственное исключение это:

http://www.boost.org/doc/libs/1_46_1/doc/h...ementation.html

принятие запроса на подключение - асинхронная операция. поэтому да, принятие подключений происходит асинхронно по отношению к остальным операциям с сокетами.

только утром до меня дошло, все базируется на winsocket'ах (если писать под винду), МФК работает примерно так:
есть цикл обработки сообщений от винды, при создании нового сокета - его данные помещяются в определенный список получателей сообщений, сокет работает асинхронно в том смысле что при поступлении данных он получает их все и уже после посылает своему объекту сообщение о принятии (OnReceive обработчик), получается что если у меня больше одного CSocket'а операции с ними будут происходить по очереди (одно сообщение за раз), но зато при Receive никаких лагов не будет - сокет уже получил данные и просит чтоб объект их обработал. (из-за цикла обработчика сообщений при моем Sleep'е замирала вся прога - сообщения для окна обрабатываются в том-же цикле )

boostcoder, можете коротко описать процес создания сервера на бусте? например какой класс за что отвечает, какой между объектами происходит обмен данными?

какого именно сервера?

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

смотри пример чата: http://www.boost.org/doc/libs/1_46_1/doc/h...o.examples.chat

Добавлено через 2 минуты и 27 секунд

ожидание данных от клиента не блокирует очередь задач io_service`а. никакой проблемы нет.

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

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


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

в общем все понятно, сейчас применил мфк, для себя буду писать только под буст )