djamshud, это то тут причём? Разумеется этим мультиплексируется обработка клиентов.

Вопрос в другом. Прочтите 1 пост.

Wolf,



Загнать их в селект?

djamshud, они и так группами опрашиваются этими функциями. Но эти функции с определённой переодичностью нужно вызывать. Вызываются они в цикле потоков (грубо говоря всё, конечно).

Это сообщение отредактировал(а) Wolf - 1.9.2010, 15:44

Wolf, извините, если я что-то не понимаю, но...

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

Добавлено через 57 секунд
Собственно, даже если состояние их не изменилось, управление вернется через указанный таймаут.

djamshud, Вы не понимаете, что речь не о сокетах и методах мультиплексирования.

Ну и чтобы вам было яснее. Клиентов более 2000. Потоков в зависимости от настройки от 1 до какого либо разумного предела (пул потоков). Потоки тормозить нельзя (тем же самым блокирующим режимом select). По этому таймаут 0. Что можно читать - читаем, что можно отослать - отсылаем (опять же чётко и без блокировок). Далее берём новую группу сокетов и обрабатываем. Непрерывно.

Это сообщение отредактировал(а) Wolf - 2.9.2010, 06:58

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

Добавлено через 2 минуты и 17 секунд
ну и по архитектуре
у каждого потока должно быть свое множество сокетов, с которым он может работать неконкурентно с другими потоками

MAKCim, пока что архитектура такова, что действительно существует конкуренция. Общий список клиентов к нему обращаются потоки для получения группы сокетов. Сокеты не закреплены за какими либо потоками. И скорее всего действительно придётся переписать механизм обработки сокетов. Вы меня заставили задуматься. Мои радужные представления о текущей архитектуре могут рухнуть   

А что посоветуете? По идее должен быть нагруженный сервер с множеством клиентов. Клиенты обмениваются между собой данными и между базами сервера. Скажем сервер видео конференций + сервер какого либо контента.

какой бы не был нагруженный сервер, всегда существует лимит одновременно обрабатываемых соединений
обусловленный производительностью системы и толщиной канала
обозначим лимит через L, а число ядер/процессоров - через N
каждому ядру/процессору соответствует поток/процесс
максимальное число соединений для него L/N
итого имеем матрицу размером L*N
каждый элемент - дескриптор (указатель, структура, ...) соединения
есть один поток, постоянно вызывающий accept()
полученный сокет диспетчеризируется одному из N потоков/процессов
каждый из N потоков/процессов циклично выполняет 3 действия
1) опрос новых соединений и добавление их в select/poll/epoll/kqueue/...
2) мультиплексирование
3) обработка
в 1) нет блокировки, т. к. у каждого потока/процесса своя часть матрицы, а доступность
нового соединения определяется флагом дескриптора
чтение и установка флага могут осуществляться параллельно без лока

MAKCim, а что насчёт общих данных и обмена сообщениями между клиентов? Тут то тоже блокировка.

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

list_replace_init имеет сложность O(1)

MAKCim, тут опять же возникает множество вопросов. Как поток которому нужно передать от клиента А клиенту Б сообщение узнает в каком потоке находится его клиент? Если не будет общего списка. Второй вопрос, кто удаляет клиентов из списка? Логично, что  поток, обрабатывающий клиента. Но удалив его дескриптор, может возникнуть такая ситуация, когда кто-то пытается в удалённый из памяти дескриптор (и, соответственно, его очередь) добавить сообщение.

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

Это сообщение отредактировал(а) Wolf - 3.9.2010, 14:05

просто ;)

поток, дергающий accept(), поддерживает map адресов клиентов и перед диспетчеризацией соединения одному из потоков добавляет {ip, id} в map
ip - адрес клиента
id - номер потока
соответственно, каждый из потоков, например через пайп, связан с ним
все пайпы мультиплексируются им равно как и listen-сокет

когда i-ый поток хочет получить номер потока, он пишет в пайп запрос и получает результат

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

матрица _не удаляется_, она статична
когда, соединение закрывается, поток достает его из select/poll/epoll/kqueue..., освобождает ресурсы и устанавливает флаг FREE в дескрипторе

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

MAKCim, спасибо, теперь многие моменты прояснились  А что можно почитать по сетевой архитектуре?

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

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