Какая польза от перехода с блокирующих сокетов на неблокирующие?

Question

У нас есть сервер приложений, разработанный на Delphi 2010 и Indy 10. Этот сервер получает более 50 запросов в секунду и работает хорошо.Но в некоторых случаях мне кажется, что Инди очень неясен.Их компоненты хороши, но иногда я копался в исходном коде только для того, чтобы понять простую вещь.В Инди не хватает хорошей документации и хорошей поддержки.
Последнее, с чем я столкнулся, было для меня большой проблемой: я должен определить, когда клиент отключается незаметно (например, когда происходит сбой или завершение работы клиента.сервер, который он отключит) и инди не смог этого сделать.Если я этого захочу, мне придется разработать алгоритм, такой как heartbeat, pooling или TCP keep-alive.Я не хочу проводить больше времени, выполняя, по крайней мере, компонентную работу.После нескольких исследований я обнаружил, что это не ошибка Indy, но это проблема всех компонентов блокирующих сокетов.

Теперь я действительно думаю об изменении ядра Сервера на другой хороший набор.Я должен признать, что я склонен использовать неблокирующий сокет.Исходя из этого, у меня есть несколько вопросов:

• Какая польза от перехода от блокирующих к неблокирующим сокетам?
• Смогу ли я обнаруживать разъединения клиента (без изящества)?
• Какой набор компонентов имеет лучший продукт?Под лучшим продуктом я имею в виду: быстрая, хорошая поддержка, хорошие инструменты и простота реализации.

Я знаю, что это должен быть субъективный вопрос, но я действительно хочу услышать это от вас.Мой первый вопрос - тот, который мне важнее всего.Мне все равно, если я должен платить 100, 500, 1000, 10000 долларов, но я хочу полное решение.Сейчас я думаю о IP * работах .

РЕДАКТИРОВАТЬ

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

И неблокирующие розетки МОГУТ обнаружить отсоединения клиента.Это факт, и он имеет хорошую документацию по всему Интернету.Неблокирующий сокет постоянно проверяет состояние сокета на наличие новых входящих данных и позволяет обнаружить, что сокет недействителен.Это не алгоритм сердцебиения.Алгоритм сердцебиения используется на стороне клиента и периодически отправляет на сервер пакеты (также известные как keep-alive), чтобы сообщить, что он еще жив.

РЕДАКТИРОВАТЬ

Яне ясно.Возможно, потому что английский не мой основной язык. Я не говорю, что можно обнаружить потерянное соединение, не пытаясь отправить или получить данные из сокета.Я хочу сказать, что каждый неблокирующий сокет может это сделать, потому что они постоянно пытаются читать из сокета новые входящие данные. Почему это так сложно понять?Если вы, ребята, загружаете и запускаете демонстрационные версии ip * works, в частности, echoserver и echoclient (оба используют TCP), вы можете протестировать их самостоятельно.Я уже проверил это, и он работает так, как я ожидал.Даже если вы используете старые TCPSocketServer и TCPSocketClient в неблокирующем режиме, вы поймете, что я имел в виду.

Answer 1

"В чем выгода перехода от блокирующих к неблокирующим сокетам?
Смогу ли я обнаруживать разъединения клиентов (без изящества)? "

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

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

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

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

Answer 2

Какая польза от перехода с блокирующих сокетов на неблокирующие?

Увеличена скорость, доступность и пропускная способность (из моего опыта).У меня был клиент IndySockets, который получал около 15 запросов в секунду, и когда я перешел непосредственно к асинхронным сокетам, пропускная способность увеличилась примерно до 90 запросов в секунду (на той же машине).В отдельном тесте производительности на сервере в дата-центре с 30-мегабитным соединением я смог получить более 300 запросов в секунду.

Смогу ли я обнаруживать разъединения клиента (без изящности))?

Это одна вещь, которую мне еще не приходилось пробовать, так как весь мой код был на стороне клиента.

Какой набор компонентов имеет лучшиетовар?Под лучшим продуктом я подразумеваю: быструю, хорошую поддержку, хорошие инструменты и простоту реализации.

Вы можете создать свой собственный клиент для сокетов за пару дней, и он может быть очень надежным и быстрым ...намного быстрее, чем большинство вещей, которые я видел "с полки".Не стесняйтесь взглянуть на мой асинхронный сокет-клиент: http://codesprout.blogspot.com/2011/04/asynchronous-http-client.html

Обновление:
(согласно комментариям Мики)

Я спрашиваюВам нужно общее техническое объяснение того, как NBS увеличивает пропускную способность по сравнению с правильно спроектированным сервером BS.

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

Вот как это обрабатывается в Windows (отсюда и соединение .NET): конечно, вы могли бы, но первое, что вы заметите в .NET ThreadPool, это то, что он имеет два типа потоков и несовпадение: пользовательские потоки и потоки портов завершения ввода / вывода.Асинхронные сокеты используют порты завершения ввода-вывода, которые «позволяют одному потоку выполнять одновременные операции ввода-вывода на разных дескрипторах или даже одновременные операции чтения и записи на одном дескрипторе». ( 1 ) Ввод-выводПотоки портов завершения специально предназначены для обработки ввода-вывода гораздо более эффективным способом, чем вы могли бы достичь, если бы использовали потоки пользователей в ThreadPool, если только вы не написали свой собственный драйвер режима ядра .

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

Есть и другие преимущества: «помимо неблокирующего преимущества перекрывающегося сокетного ввода-вывода, другим преимуществом является лучшая производительность, поскольку вы сохраняете копию буфера между буфером стека TCPи пользовательский буфер для каждого вызова ввода-вывода. "(* +1041 * 3 * * один тысяча сорок два)

Answer 3

Aahhrrgghh - миф о возможности всегда обнаруживать «сброшенные» соединения. Если вы включите питание компьютера с клиентским подключением, то сервер не сможет без отправки данных сказать, что соединение «мёртвое». Это через дизайн протокола TCP. Не верьте мне на слово - прочтите эту статью ( Обнаружение полуоткрытых (удаленных) соединений сокетов TCP / IP ).

Answer 4

В Windows есть третий вариант, который перекрывается с вводом / выводом.Неблокирующие сокеты - это важная модель, использующая сообщения Windows, разработанные, чтобы избежать «блокирования» однопоточных приложений с графическим интерфейсом во время ожидания данных.Современное приложение IMHO было бы лучше спроектировано с использованием потоков и перекрывающихся операций ввода-вывода.

См. Например http://support.microsoft.com/kb/181611

Answer 5

Я использую библиотеки Indy и Synapse TCP с хорошими результатами уже несколько лет, и не нашел в них каких-либо showtoppers.Я использую библиотеки в потоках - на стороне клиента и сервера, стабильность и производительность не были проблемой.(Шесть тысяч запросов и ответных сообщений в секунду и более на сервере, работающем в той же системе, типичны.)

Блокирующие сокеты очень полезны, если протокол более продвинутый, чем простой «отправить строку / получитьстрока».Неблокирующие сокеты вызывают более высокую связь обработчиков протоколов сообщений с логикой чтения / записи сокетов, поэтому я быстро отошел от неблокирующего кода.

Ни одна библиотека не может преодолеть ограничения протокола TCP / IP в отношенииобнаружение потери соединения.Только попытка прочитать или отправить данные может сказать, что соединение все еще присутствует.

Answer 6

В этой статье объясняются основные различия между блокировкой и неблокировкой:

Введение в Indy Чедом З. Ховером

ПлюсыБлокировка

• Простота программирования - Блокировка очень проста в программировании.Весь код пользователя может существовать в одном месте и в последовательном порядке.
• Легко переносить на Unix - Так как Unix использует блокирующие сокеты, переносимый код может быть легко написан.Indy использует этот факт для достижения единого исходного решения.
• Хорошо работают в потоках - Поскольку блокирующие сокеты являются последовательными, они по своей сути инкапсулированы и поэтому очень легко используются в потоках.

Минусы блокировки

• Пользовательский интерфейс «заморозить» с клиентами - Блокирующие вызовы сокетов не возвращаются, пока они не выполнили свою задачу.Когда такие вызовы выполняются в главном потоке приложения, приложение не может обрабатывать сообщения интерфейса пользователя.Это заставляет пользовательский интерфейс «зависать», потому что обновления, перерисовки и другие сообщения не могут быть обработаны, пока вызовы блокирующего сокета не вернут управление циклу обработки сообщений приложений.

Он также написал:

Блокировка НЕ ​​ЗЛА

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

Это не an issue of all blocking sockets components, что они не могут обнаружить отключение клиента.В этой области у неблокирующих компонентов нет технических преимуществ.