Можно ли использовать select () для реализации тайм-аута чтения / записи в один сокет? - PullRequest
4 голосов
/ 15 марта 2010

У меня приложение для обработки сетевых коммуникаций с блокировкой звонков. Каждый поток управляет одним соединением. Я добавил время ожидания для операции чтения и записи, используя команду select перед чтением или записью в сокет.

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

Ответы [ 3 ]

4 голосов
/ 15 марта 2010

Да, это не проблема, и вы хотите, чтобы некоторые механизмы тайм-аута не пропускали ресурсы от клиентов с плохим поведением и т.д.

Обратите внимание, что наличие большого количества потоков еще более неэффективно, чем выбор, работающий с большим количеством сокетов.

2 голосов
/ 15 марта 2010

Если вы думаете, что выбор неэффективен с большим количеством сокетов, попробуйте обрабатывать большое количество сокетов с одним потоком на сокет. Вы находитесь в мире боли. Как будто у вас будут проблемы с масштабированием до 1000 потоков.

Что я делал в прошлом, так это:

  • Групповые розетки в группах X (512, 1024).
  • Пропустите один или два потока по этим группам и выберите () - затем передайте сокеты с новыми данными в очередь.
  • имеют несколько рабочих потоков, работающих с этими сокетами с новыми данными. Сколько зависит, сколько мне нужно, чтобы максимально использовать процессор;)

Таким образом, я не получаю супер über select () с ТОННЫМИ предметов, и я также не трачу смехотворное количество памяти на потоки (подсказка: каждому потоку нужен свой собственный стек. С ТОЛЬКО 2 МБ, то есть 2 ГБ на 1000 сокетов - говорить о неэффективном) и тратить огромное количество ресурсов процессора на выполнение бесполезных переключений контекста.

0 голосов
/ 15 марта 2010

Вопрос с thread / select заключается в том, хотите ли вы, чтобы клиенты не блокировали друг друга. Если это не проблема, то работайте однопоточными. Если это так, выберите подходящую схему потоков (1 поток на соединение, рабочие потоки на соединение, рабочий поток на запрос, ...).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...