Lazy сокеты - масштабируемость?

Question

Спрашивая больше в теории, как я могу построить сервер (или приложение), который использует ленивые сокеты? Я представляю веб-приложение, которое переносит все свои данные через обмены JSON на центральный API-подобный сервлет. Я мог бы оставить HTTP-соединение открытым после передачи всех данных, чтобы написать больше клиенту, как своего рода ленивая технология push. Браузер также может снова подключиться после таймаута, который закрывает сокет.

Опрос этой модели, как бы написать приложение таким образом, чтобы не потреблять грузовики с памятью при экспоненциальном ветвлении? Будет ли каждый поток обрабатывать одно или несколько соединений? Как каждый может обнаружить новые данные для передачи? - по-видимому, мне нужен диалог между потоками, а не каждый поток активно искать данные самостоятельно? Если бы я написал родительский поток, породивший x + 1 дочерние потоки, каждый поток был бы 1: 1 или много: 1 с клиентами? Могу ли я столкнуться с проблемами взаимоблокировки? Каков объем памяти каждого дополнительного обработчика соединения?

У кого-нибудь есть мысли по этому поводу? Мне интересно, как это будет выглядеть в теории, чем практика.

Answer 1

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

Answer 2

Я предлагаю вам взглянуть на Twisted. Он использует легкий подход с одним процессом обработки async IO, а затем несколькими рабочими процессами. Поскольку работники могут блокировать вызовы файлов и баз данных, их проще синхронизировать в поточных рабочих. Затем основная часть открытых сокетов может обрабатываться одним родительским потоком с использованием async IO.