Событийно-ориентированный HTTP-сервер на C# с помощью Rx и HttpListener

[@arilou_camper]

Спасибо, что популяризируете Rx. Незаслуженно обойденная вниманием разработчиков на пост-советском пространстве библиотека.

[@Sergey55]

Каждый раз когда я читаю статьи на данную тему у меня возникает один глупый вопрос, а зачем это нужно? Нет, правда? Разве веб сервер не обрабатывает каждое подключение в отдельном потоке? А если так, то вообще не вижу никакого смысла. Если мы получаем какие-то данные из базы и т.д., то мы делаем это для того чтобы потом их каким-либо образом обработать и отправить на клиент. Даже если сценарий просто сохраняет данные в БД, то он должен оповестить клиента о результате выполнения данной операции и ему в любом случае необходимо дождаться окончания выполнения операции… А в данном, случае, насколько я понимаю будут создаваться дочерние потоки, на создание которых тоже необходимо какое-то количество ресурсов. Может кто-нибудь привести конкретный пример на котором было бы наглядно видно для чего все это необходимо?

[@Tasman99]

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

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

[@szKarlen]

>Каждый раз когда я читаю статьи на данную тему у меня возникает один глупый вопрос, а зачем это нужно? Нет, правда? Разве веб сервер не обрабатывает каждое подключение в отдельном потоке? А если так, то вообще не вижу никакого смысла.

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

>Если мы получаем какие-то данные из базы и т.д., то мы делаем это для того чтобы потом их каким-либо образом обработать и отправить на клиент. Даже если сценарий просто сохраняет данные в БД, то он должен оповестить клиента о результате выполнения данной операции и ему в любом случае необходимо дождаться окончания выполнения операции… А в данном, случае, насколько я понимаю будут создаваться дочерние потоки, на создание которых тоже необходимо какое-то количество ресурсов.

во-первых, весь смысл заключается в том, чтобы «отпустить» обрабатывающий поток от ожидания завершения текщей операции, заменив на IOCP. таким образом при неблокирующем IO ваш сервер всегда будет в режиме принятия соединений от клиентов.
во-вторых, по дефолту используется ThreadPoolSheduler, который сродни ThreadPool.QueueUserWorkItem. новые потоки не будут создаваться, если конечно вы это явно не укажите:

var handler = server.Where(ctx => ctx.Request.Url.EndsWith("/hello"))
     .ObserveOn(Scheduler.NewThread)
     .Subscribe(ctx => ctx.Respond(new StringResponse("world")));


существует несколько режимов Sheduler'a, включая использование task'ов. советую обратить внимание на страницу MSDN.