Каков идиоматический способ программирования асинхронных сокетов в Delphi?

Для асинхронных вещей попробуйте ICS

http://www.overbyte.be/frame_index.html?redirTo=/products/ics.html

Я обнаружил, что Indy, несмотря на более простую концепцию в начале, неудобен в управлении из-за необходимости уничтожать сокеты для освобождения потоков при завершении работы приложения. Кроме того, у меня перестала работать библиотека Indy после обновления патча ОС. ScktComp хорошо работает для моего приложения.

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

Как обычно люди, пишущие сетевой код в Delphi, используют асинхронный ввод-вывод с перекрывающимися сокетами в стиле Windows?

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

Indy 9 показался нам в основном надежным, быстрым и надежным. Однако переход на Indy 10 для Tiburon вызывает у меня небольшое беспокойство.

@Mike: «... необходимость убивать сокеты, чтобы освободить потоки ...».

Это заставило "а?" пока я не вспомнил, что наша библиотека потоков использует метод, основанный на исключениях, для безопасного уничтожения «ожидающих» потоков. Мы вызываем QueueUserAPC, чтобы поставить в очередь функцию, которая вызывает исключение C++ (НЕ производное от класса Exception), которое должно быть перехвачено только нашей процедурой-оболочкой потока. Все деструкторы вызываются, поэтому все потоки завершаются чисто и убираются на выходе.

«Синхронные сокеты — это не то, что мне нужно».

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

В качестве побочного вопроса, вы можете найти эти ссылки интересными. Они оба немного устарели и больше *nxy, чем Windows. Второй подразумевает, что в правильной среде потоки могут быть не такими плохими, как вы думаете.

Проблема C10K

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

@Chris Miller - то, что вы сказали в своем ответе, фактически неверно.

Асинхронизация в стиле сообщений Windows, доступная через WSAAsyncSelect, действительно в значительной степени является обходным путем из-за отсутствия надлежащей модели многопоточности в дни Win 3.x.

Однако .NET Begin/End не использует дополнительные потоки. Вместо этого он использует перекрывающийся ввод-вывод, используя дополнительный аргумент в WSASend / WSARecv, в частности, перекрывающуюся процедуру завершения, чтобы указать продолжение.

Это означает, что стиль .NET использует поддержку асинхронного ввода-вывода ОС Windows, чтобы предотвратить сжигание потока путем блокировки сокета.

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

Вот почему важно использовать асинхронный ввод-вывод, если вы хотите масштабироваться, а также почему .NET не, я повторяю, не просто «использует потоки». , [...] просто управляемый Framework».

@Roddy - я уже читал ссылки, на которые вы указываете, на обе они ссылаются из презентации Пола Тима «Тысячи потоков и блокирующий ввод-вывод - старый способ написания серверов Java снова стал новым».

Однако некоторые вещи, которые не обязательно бросаются в глаза из презентации Пола, заключаются в том, что он указал -Xss:48k для JVM при запуске и что он предполагает, что реализация NIO JVM эффективна, чтобы она была действительной. сравнение.

Indy не указывает столь же уменьшенный и строго ограниченный размер стека. В кодовой базе Indy нет вызовов BeginThread (процедура создания потока Delphi RTL, которую следует использовать в таких ситуациях) или CreateThread (необработанный вызов WinAPI).

Размер стека по умолчанию хранится в PE, а для компилятора Delphi он по умолчанию равен 1 МБ зарезервированного адресного пространства (пространство выделяется ОС страница за страницей фрагментами по 4 КБ; фактически компилятору необходимо генерировать код для обращения к страницам, если в функции содержится >4 КБ локальных переменных, поскольку расширение контролируется ошибками страниц, но только для самой нижней (защитной) страницы в стеке). Это означает, что у вас закончится адресное пространство после максимум 2000 одновременных потоков, обрабатывающих соединения.

Теперь вы можете изменить размер стека по умолчанию в PE с помощью директивы {$M minStackSize [,maxStackSize]}, но это повлияет на все потоки, включая основной поток. Я надеюсь, что вы не будете делать много рекурсии, потому что 48 КБ или (аналогично) - это не так много места.

Теперь, прав ли Пол в отношении неэффективности асинхронного ввода-вывода, в частности, для Windows, я не уверен на 100% - мне нужно измерить это, чтобы быть уверенным. Однако я точно знаю, что аргументы в пользу того, что многопоточное программирование проще, чем асинхронное программирование на основе событий, представляют собой ложную дихотомию.

Асинхронный код не обязательно должен быть основан на событиях; он может быть основан на продолжении, как в .NET, и если вы укажете замыкание в качестве своего продолжения, вы получите состояние, поддерживаемое для вас бесплатно. Кроме того, преобразование из линейного кода в стиле потока в асинхронный код в стиле с передачей продолжения может быть выполнено компилятором механически (преобразование CPS является механическим), поэтому ясность кода также не требуется.

Существуют бесплатные компоненты сокетов IOCP (порты завершения): http://www.torry.net/authorsmore.php?id=7131 (включая исходный код)

"От Набережных Сергей Н.. Высокопроизводительный сокет-сервер на базе Windows Completion Port и с использованием Windows Socket Extensions. Поддерживается IPv6."

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

Indy использует синхронные сокеты, потому что это более простой способ программирования. Асинхронная блокировка сокетов была добавлена ​​в стек winsock еще во времена Windows 3.x. Windows 3.x не поддерживала потоки, и там вы не могли выполнять ввод-вывод сокетов без потоков. Дополнительную информацию о том, почему Indy использует модель блокировки, см. в этой статье.

С классами ScktComp вам нужно использовать сервер ThreadBlocking, а не тип сервера NonBlocking. Используйте событие OnGetThread, чтобы передать параметр ClientSocket новому потоку вашей разработки. Создав экземпляр унаследованного экземпляра TServerClientThread, вы создадите экземпляр TWinSocketStream (внутри потока), который можно использовать для чтения и записи в сокет. Этот метод избавляет вас от попыток обрабатывать данные в обработчике событий. Эти потоки могут существовать только в течение короткого периода времени, необходимого для чтения или записи, или зависать на время с целью повторного использования.

Тема написания сервера сокетов довольно обширна. Существует множество техник и практик, которые вы можете применить. Метод чтения и записи в тот же сокет, что и в TServerClientThread, прост и подходит для простых приложений. Если вам нужна модель для высокой доступности и высокой параллелизма, вам нужно изучить шаблоны, такие как шаблон Proactor.

Удачи!