Netspirit, спасибо!
А когда запустится поток чтения данных?

При AutoReceive=True запускается сразу после успешного подключения. Иначе вручную нужно вызвать doStartReceiving.

Редактировалось 2 раз(а), последний 2017-03-08 11:58:13

Netspirit, спасибо!

Времени прошло значительно больше чем пара месяцев, еще не принято решение о добавлении этих компонентов в стандартную палитру?

Там автор все еще что-то шерстит.

Ну, уже вроде как бы всё устаканилось. Но, конечно, ещё будут доработки.

Этот компонент только со String работает, Stream нельзя?

Нет. Реализация собственных протоколов для отправки произвольных данных - /topic/65137

Netspirit, Если не затруднит объясни пожалуйста про потоки внутри сервера и клиента.
Собственно мне требуется на клиенте проверять наличие новых данных в БД, затем паковать их и отправлять на сервер.
Одно из условий - пока сервер обрабатывает полученный пакет от клиента, клиент не должен слать последующие пакеты.
Когда сервер обработает пакет он отключит клиента, собственно после отключения можно будет повторно подключиться и отправить следующие данные.
Такая схема с отключением\подключением сделана ввиду того что данные шлются в HTTP POST запросах, ну и потому что появляются они не часто и удерживать соединение не имеет смысла.

Вопрос по потокам следующий:
Какие события происходят в одном потоке а какие в разных?
onConnect\onDisconnect это события одного потока?
onReceive - другого?
Правильно ли в моей схеме используется критическая секция?

События onConnect/onErrorConnect происходят либо в потоке, вызвавшем doConnect (при AsyncConnect=False), либо в параллельном потоке (при AsyncConnect=True)

События onSend/onErrorSend происходят либо в потоке, вызвавшем doSend, либо в параллельном потоке после doSendAsync

Событие onReceive происходит в параллельном потоке чтения данных, onClientConnect - в параллельном потоке приёма подключений.

Событие onDisconnect/onClientDisconnect происходит либо в потоке, вызвавшем doDisconnect, либо в параллельном потоке чтения данных.

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

Если свойство AsyncEvents=False, то все перечисленные события, происходящие в параллельных потоках, вызываются из главного потока приложения (очереди сообщений). Для невизуальных приложений (не имеющих очереди сообщений), AsyncEvents всегда True.

Вроде правильно, только AsyncEvents наверное должно быть True. Аккуратно следует использовать критическую секцию на событиях из главного потока (например, события от оконных элементов). Возможна такая ситуация, когда параллельный поток заходит в секцию, затем вызывает метод какого-то визуального компонента, в результате которого генерируется оконное сообщение и метод должен дождаться обработки этого сообщения. Тогда, если на это сообщение есть событие, использующее ту же критическую секцию, произойдёт deadlock: праллельный поток ждёт обработки сообщения, а главный поток не может завершить его обработку, так как ждёт освобождения критической секции параллельным потоком.

Редактировалось 4 раз(а), последний 2017-04-20 16:20:05

Как быть с сетевыми контроллерами которые на каждую принятую команду отвечают что-либо?
У меня происходит следующее - есть массив команд которые нужно послать по очереди (шлю через перебором через ArrayEnum), если AsyncEvents=False то контроллер отрабатывает все команды и на каждую отвечает, если AsyncEvents=True то ответы получаю не на все отправленные команды..

--- Добавлено в 2017-04-20 22:21:52

И еще вопросы:

1) Есть поток с задержкой 1000ms, он вызывает подключение к серверу и отправку данных.
Например данных оказалось больше или скорость канала просела и за 1000ms мы не успеваем отправить, что в этом случае происходит с потоком по истечению 1000ms?
2) Нужно ли использовать асинхронные события? Можно какой-нибудь пример ситуации для чайников))



Редактировалось 3 раз(а), последний 2017-04-20 22:22:14

Если данные отправляются из главного потока (например, по командах обычного таймера), то при AsyncEvents=False событие onReceive не произойдёт, пока не отработает событие таймера (в твоем случае когда весь список команд будет перебран). После отработки поток приёма данных получает возможность вызвать все необходимые события onReceive.
При AsyncEvents=True (или при переборе команд с вызовом doSend не из главного потока) событие onReceive может произойти в процессе перебора - ты шлешь очередную команду очередному клиенту и в это самое время может произойти событие onReceive как ответ от предыдущего клиента.

Мне кажется, тут нужно менять логику в схеме для реализации "запрос-ответ". Это не принципиально зависит от AsyncEvents - в любом случае тебе нужно дождаться прихода ответа, причем, в правильном порядке.
Сделать это можно так. Специальный паралельный поток сбрасывает событие (компонент Events) затем шлет одну команду и останавливается на ожидание срабатывания события (компонент WaitObject). Событие onReceive выполняет необходимую обработку ответа, а затем сигналит то же событие Events, позволяя отправляющему потоку продолжить исполнение и отправить следующую команду.

Если под "потоком" имеется в виду компонент Thread, то в этом случае ничего не происходит - поток остановится, пока данные не будут отправлены. Если данные не были приняты клиентом на протяжении SendTimeout, сработает событие onErrorSend.
Но тут есть одна проблемка: у сокета есть свой буфер. И если при отправке в буфере есть свободное место, то новые данные будут записаны в буфер, метод doSend/doSendAsync отработает сразу, событие onSend будет получено. При этом, не факт что клиент эти данные получит: если после этого глюкнет сеть или клиент отключится, то мы получим событие onDisconnect (поток приема данных обнаружит ошибку чтения сокета, хотя, возможно, и не всегда), но мы не сможем узнать сколько реально клиент смог принять данных из буфера перед обрывом. Отправка следующих данных выдаст onErrorSend.
Если в буфере при отправке нет свободного места, отправляющий поток приостановится до освобождения буфера.

Редактировалось 2 раз(а), последний 2017-05-25 11:27:00

Запутался...

Правильно я понимаю что главный поток - это поток который создается системой при запуске ПО, далее из него мы можем вызывать уже дочерние потоки?
В таймерах и компоненте Thread есть задержка между итерациями, а как устроен главный поток? Грубо говоря запустили мы программу...главный поток вызвал какую-то функцию, цепочка событий началась. У него так же есть задержка?
п.с. спасибо за терпение, вы очень интересно объясняете))

Если вызвать doSend из запущенного тобой параллельного потока, то главный поток в процессе doSend будет не занят и сможет выдавать событие onReceive одновременно с твоим doSend. Это и имелось в виду.

Да. При запуске приложения система создаёт один поток, и в нём выполняет код, расположенный по адресу, указанному в специальном месте исполняемого файла (называется "точка входа"). После отработки кода в этом месте приложение завершает работу (даже если запустило другие потоки - они принудительно останавливаются). Для того, чтобы приложение постоянно оставалось запущеным и выполняло команды пользователя, в главном потоке оно должно запустить цикл, ожидающий какого-либо условия для завершения своей работы, ну и команд от пользователя.
GUI ("оконное") приложение реализует в этом цикле с помощью функций Windows выборку оконных сообщений, передачу их на обработку созданным в этом приложении окнам. Обычно, этот цикл завершается, когда будет закрыто первое созданое приложением окно (а точнее, в очередь сообщений будет послано сообщение WM_QUIT). Если посмотреть исходный код проектов Delphi, то можно увидеть, что сначала создается главное окно, а затем вызывается процедура Application.Run(), содержащая такой цикл. А пользователь уже управляет приложением, используя элементы управления в главном и других окнах. Всё, что он нажимает в окнах, попадает в виде сообщения в главный цикл, тот передаёт его оконной процедуре окна, в котором оно произошло, а она ищет обработчик, назначенный программистом для данного сообщения (например, в панели событий Delphi IDE).

Если функция выборки очередного сообщения показывает, что сообщений нет, цикл вызывает специальную функцию, которая ждёт появления сообщения. То-есть, главный поток в этот момент ничего не делает. Когда появляется сообщение, поток возобновляет свою работу и идёт на следующую итерацию цикла обработки сообщений.

Да, только их природа разная - в Thread это тупо цикл и функция Sleep(), а в Таймере, возможно, то же самое, только где-то в недрах системы, и каждая итерация сопровождается посылкой в наш главный цикл сообщения таймера. MMTimer отличается от простого Timer тем, что не шлёт оконных сообщений, а прямо вызывает нужное событие "в параллельном потоке". И этим он полностью по функционалу аналогичен нашему Thread с задержкой.

Редактировалось 2 раз(а), последний 2017-05-25 11:31:56

Типа такого?
п.с. а Events можно использовать с паралельным потоком?