Что идиоматический путь состоит в том, чтобы сделать асинхронное программирование сокета в Delphi?
find() рассмотрит подстроку относительно регулярного выражения, где в качестве matches() рассмотрит полное выражение.
find() вернет true, только если подстрока выражения совпадает с шаблоном.
public static void main(String[] args) {
Pattern p = Pattern.compile("\\d");
String candidate = "Java123";
Matcher m = p.matcher(candidate);
if (m != null){
System.out.println(m.find());//true
System.out.println(m.matches());//false
}
}
10 ответов
Поскольку асинхронный материал пробует ICS
http://www.overbyte.be/frame_index.html?redirTo=/products/ics.html
Я нашел, что Инди, в то время как более простое понятие в начале, неудобно управлять из-за потребности уничтожить сокеты к свободным потокам при завершении приложения. Кроме того, я сделал, чтобы библиотека Indy прекратила работать после обновления патча операционной системы. ScktComp работает хорошо на мое приложение.
@Roddy - Синхронные сокеты не то, что я после. Запись целого потока ради возможно долговечного соединения означает ограничение объема параллельных соединений к количеству потоков, которые может содержать процесс. Так как потоки используют много ресурсов - зарезервированное адресное пространство стека, фиксировавшая стековая память и переходы ядра для контекстных переключений - они не масштабируются, когда необходимо поддерживать сотни соединений, а тем более тысячи или больше.
"Синхронные сокеты не то, что я после".
Понятый - но я думаю в этом случае, что ответ на Ваш исходный вопрос - то, что просто нет идиомы Delphi для асинхронного сокета IO, потому что это - на самом деле узкоспециализированное и редкое требование.
Как второстепенный вопрос, Вы могли бы найти эти ссылки интересными. Они и немного стары, и больше *nxy, чем Windows. Второй подразумевает, что - в правильной среде - потоки не могли бы быть настолько плохими, как Вы думаете.
Почему события являются плохой идеей (для серверов высокого параллелизма)
То, что нормальный путь люди пишут сетевой код в стиле Windows использования Delphi, перекрыло асинхронный сокет ввод-вывод?
Ну, Инди была 'стандартной' библиотекой для сокета ввод-вывод долгое время теперь - и это основано на блокирующихся сокетах. Это означает, хотите ли Вы асинхронное поведение, Вы используете дополнительный поток (потоки) для соединения/читавшего/писания данных. По моему мнению это - на самом деле главное преимущество, поскольку нет никакой потребности управлять любым видом навигации конечного автомата или беспокойством об обратном вызове procs или подобном материале. Я нахожу, что логика моего потока 'чтения' менее нарушена и намного более портативная, чем неблокирование сокетов позволило бы.
Инди 9 была главным образом бомбоубежищем, быстрым и надежным для нас. Однако перемещение к Инди 10 для Тибурона вызывает меня немного беспокойства.
@Mike: "... потребность уничтожить сокеты к свободным потокам...".
Сделанный идет "ха?" пока я не помнил, что наша библиотека поточной обработки использует основанную на исключении технику для уничтожения потоков 'ожидания' безопасно. Мы называем QueueUserAPC для организации очередей функции, которая повышает исключение C++ (НЕ полученный из класса Исключение), который должен только быть пойман нашей процедурой обертки потока. Все деструкторы называют так потоками, которые все завершают чисто и убирают на выходе.
@Chris Miller - То, что Вы заявили в своем ответе, фактически неточно.
Асинхронный стиль сообщения Windows, как доступный через WSAAsyncSelect, является действительно в основном обходным решением из-за отсутствия надлежащей модели потоков в Win 3.x дни.
.NET Начинает/Заканчивает, однако, не использует дополнительные потоки. Вместо этого это использует, перекрыл ввод-вывод, с помощью дополнительного аргумента на WSASend / WSARecv, конкретно перекрытая стандартная программа завершения, для определения продолжения.
Это означает, что стиль.NET использует Windows асинхронная поддержка ввода-вывода ОС, чтобы не записывать поток путем блокирования на сокете.
Так как потоки являются вообще говоря, дорогими (если Вы не укажете очень небольшой размер стека к CreateThread), имение потоков, блокирующихся на сокетах, будет мешать Вам масштабироваться к 10 000 с параллельных соединений.
Поэтому важно, чтобы асинхронный ввод-вывод использовался, если Вы хотите масштабироваться, и также почему.NET не, я повторяюсь, не, просто "с помощью потоков, [...] просто управляемых Платформой".
@Roddy - я уже прочитал ссылки, на которые Вы указываете, на них и ссылаются от презентации Paul Tyma "Тысячи Потоков и Блокирующегося ввода-вывода - старый способ записать, что Серверы Java являются Новыми снова".
Некоторые вещи, которые не обязательно переходят из презентации Paul, однако, то, что он указал-Xss:48k к JVM на запуске, и что он предполагает, что внедрение NIO JVM эффективно для него, чтобы быть допустимым сравнением.
Инди не указывает столь же съежившийся и сильно ограниченный размер стека. Нет никаких вызовов к BeginThread (Delphi стандартная программа создания потока RTL, которую необходимо использовать для таких ситуаций), или CreateThread (необработанный вызов WinAPI) в кодовой базе Инди.
Размер стека по умолчанию хранится в PE, и для компилятора Delphi он принимает значение по умолчанию к 1 МБ зарезервированного адресного пространства (пространство фиксируется постранично ОС в блоках 4K; на самом деле компилятор должен сгенерировать код для касания страниц, если существует> 4K местных жителей в функции, потому что расширением управляют отсутствия страницы, но только для самого низкого (защита) страница в стеке). Это означает, что Вы собираетесь закончиться адресное пространство после макс. 2 000 параллельных потоков, обрабатывающих соединения.
Теперь, можно изменить размер стека по умолчанию в PE с помощью {$M minStackSize [maxStackSize]} директива, но это будет влиять на все потоки, включая основной поток. Я надеюсь, что Вы не делаете большой рекурсии, потому что 48K или (подобный) не является большим количеством пространства.
Теперь, ли Paul прав относительно невыполнения асинхронного ввода-вывода для Windows, в частности, я не на 100% уверен - я должен был бы измерить его, чтобы быть бесспорным. То, что я действительно знаю, однако, то, что аргументы о потоковом программировании, являющемся легче, чем асинхронное основанное на событии программирование, представляют ложную дихотомию.
Асинхронный код не должен быть основан на событии; это может быть основано на продолжении, как он находится в.NET, и если Вы указываете закрытие как свое продолжение, Вы получаете состояние, сохраняемое для Вас бесплатно. Кроме того, преобразование от линейного кода стиля потока до передающего стиля продолжения, асинхронный код может быть сделан механическим устройством компилятором (преобразование CPS является механическим устройством), так там должны не быть никакой стоимостью в ясности кода также.
Существует свободный IOCP (порты завершения) компоненты сокета: http://www.torry.net/authorsmore.php?id=7131 (включенный исходный код)
"Naberegnyh Sergey N.. Высокопроизводительный сервер сокета на основе Windows Completion Port и с использованием Windows Socket Extensions. IPv6 поддерживается".
я нашел его при взгляде лучших компонентов/библиотеки к rearchitecture мой небольшой сервер мгновенного обмена сообщениями. Я еще не попробовал его, но это выглядит хорошим кодированный как первое впечатление.
Инди использует синхронные сокеты, потому что это - более простой способ запрограммировать. Асинхронное блокирование сокета было чем-то добавленным к стопке winsock назад в дни Windows 3.x. Windows 3.x не поддерживал потоки, и там Вы не могли сделать, снабжают ввод-вывод сокетом без потоков. Для некоторой дополнительной информации о том, почему Инди использует блокирующуюся модель, см. эту статью.
Сокет.NET. Вызовы BeginRead/EndRead используют потоки, этим просто управляет Платформа вместо Вами.
@Roddy, Инди 10 была связана Delphi с тех пор в Delphi 2006. Я нашел что, мигрировав от Инди 9 к Инди 10, чтобы быть прямой задачей.
С классами ScktComp необходимо использовать сервер ThreadBlocking, а не тип сервера NonBlocking. Используйте событие OnGetThread для вручения от ClientSocket param новому потоку изобретения. После того как Вы инстанцировали наследованного экземпляра TServerClientThread, Вы создадите экземпляр TWinSocketStream (в потоке), который можно использовать в чтение и записать в сокет. Этот метод получает Вас далеко от попытки обработать данные в конечном счете обработчик. Эти потоки могли существовать в течение просто короткого периода, должен читать или записать или держаться в течение какого-то времени в целях того, чтобы быть снова использованным.
Предмет записи сервера сокета довольно обширен. Существует много методов и методов, которые Вы могли принять решение реализовать. Метод чтения и записи в тот же сокет с в TServerClientThread является прямым и прекрасным для простых приложений. При необходимости в модели для высокой доступности и высокого параллелизма затем, необходимо изучить шаблоны как шаблон Проагента.
Удачи!