Russian Qt Forum

Коллеги, подскажите, пожалуйста, как организуется ожидание данных в асинхронном режиме?
Задача - взаимодействие по типу запрос/ответ с устройством (контроллером) через сокет. Есть функция, которая выполняет передачу запроса в сокет (функция запроса). Чтение ответа от контроллера выполняется асинхронно, по сигналу readyRead (обработчик ответа).
Мне нужно в функции запроса дождаться ответа железяки, прочесть его и отправить куда надо. Т.е. в функции нужно организовать ожидание и фиксацию завершения работы обработчика ответа. Как передать данные - отдельный вопрос, и речь не о нем.

Так может вам синхронный режим нужен?

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

Стоп.

Вы уж определитесь - в функции запроса дождаться ответа железяки. И как вы в этот момент примите другие кадры? насколько я понимаю вы из ф-ции выходить не хотите, потому никак, скорее всего :)

Ну хотя бы повиснуть на мутексе (а может еще лучше на семафоре), который асинхронка откроет. Или я чего-то не понял в вопросе 

После отправки запроса запускаем разовый сторожевой таймер. Время ожидания должно определяться в протоколе обмена с контроллером. Сработал таймер - значит контроллер не ответил за заданное время, ответил контроллер до срабатывания - останавливаем таймер (если есть объект) или ставим флаг игнорирования (для статического QTimer::singleShot), который обрабатываем в слоте таймера. Только при приеме данных надо помнить о том, что данные могут приходить порциями, т.е. остановка таймера только после чтения полного ответа.

Собственно, чего темнить - обмен по modbus TCP. Задумка была такая - запросы клиенты передают запросы каждый в своем порожденном процессе. Т.е., подключился к контроллеру, передал, отключился. И ждет некоторое время.
А все ответы получает основной процесс по 502-му порту и складывает в кучку, например, в БД. Вот клиентский процесс должен подождать, когда его ответ появится и забрать.
Возможно, я ошибаюсь - хотел потом проверить. Контроллер можно настроить на любой порт, но сервер всегда должен слушать 502-й. Вот это я и хотел использовать.
Есть, конечно, другое решение - два последовательных запроса (передача запроса, потом получение ответа).

читай спецификацию modbus TCP, может так и невозможно сделать

С контроллером (железякой) должен общаться только программный сервер в режиме "Master-Slave", причем мастер - это сервер. Он же по сети принимает запросы от всех клиентов и формирует очередь запросов к контроллеру. После исполнения запроса контроллером происходит анализ ответа и определение клиента, пославшего этот запрос. И только этому клиенту отправляется ответ (или уведомление о таймауте его запроса). Железяка все-равно не будет исполнять запросы параллельно.

Складывать запросы от клиентов в БД - очень плохая идея. Выполненный запрос никому уже не нужен, следовательно БД будет постоянно модифицироваться и времени на дисковые операции ох как много уйдет. Гораздо эффективнее использовать что-то типа QQueue<QByteArray> с контролем размерности. К примеру, ограничить на 1000 элементов, а при достижении потолка тормозить клиентов.

Может и нельзя. А я разве задавал вопрос о том, можно ли так сделать? Контроллеры бываю разные...

Немного не так. Контроллер тупо транслирует запрос в сеть RS-485. То устройство, которому он адресован, его исполняет и отвечает в соответствии с спецификацией функции. Контроллер просто передает ответ обратно в сеть TCP/IP.
Какому клиенту передать ответ, решает сервер - запрос и ответ имеют для этого идентификатор транзакции. Собственно, мой вопрос и касался того, как мне лучше замкнуть транзакцию.

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

Результат выполнения запроса нужен, но только результат, а не сам запрос. Для модбаса запрос - номера функции или регистров устройства, зачем хранить этот байтовый набор? А вот результат, описывающий состояние системы, - однозначно нужен. А 485 интерфейс вообще полудуплексный - одновременно болтать и слушать не получится.

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

Не вижу проблемы. У меня был тупо QEventLoop c таймером в 500 мс. Если за 500 мс не пришёл ответ - следующий запрос, текущее устройство недоступно.

Спасибо!

Как бы не за что, но это изврат на самом деле :D

Асинхронная передача с циклом, с таймером, превращаемая в синхронную :D

PS я пользуюсь :D

Наоборот, мне понравилось. Я напомню - у меня два разных процесса, один пишет в БД, второй - читает то, что пишет первый. Первый дописал, дал сигнал. Второй по этому сигналу прочел данные и завершился. Предельное время ожидания задается таймером, для случаев, когда первый загнется.
Все красиво, и, главное, просто. Правда, не знаю, можно ли сигналы Qt передавать между процессами linux. Но, думаю, это решается, если не так, то по-другому.

PS Кстати, вспомнил про Unix-сокеты (AF_UNIX).

Передавать нельзя напрямую, но есть библиотеки на qt-project которые позволяют это делать даже через tcp :)