Ожидание данных в асинхронном режиме

[sergek]

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

[Bepec]

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

[sergek]

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

[Bepec]

Стоп.

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

[Igors]

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

[Hellraiser]

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

[sergek]

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

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

[qate]

Собственно, чего темнить - обмен по modbus TCP.

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

[Hellraiser]

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

[Hellraiser]

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

[sergek]

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

Может и нельзя.

The listening TCP port 502 is reserved for MODBUS communications. It is mandatory to listen by default on that port. However, some markets or applications might require that another port is dedicated to MODBUS over TCP. For that reason, it is highly recommended that the clients and the servers give the possibility to the user to parameterize the MODBUS over TCP port number. It is important to note that even if another TCP server port is configured for MODBUS service in certain applications, TCP server port 502 must still be available in addition to any application specific ports.

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

[sergek]

После исполнения запроса контроллером происходит анализ ответа и определение клиента, пославшего этот запрос. И только этому клиенту отправляется ответ (или уведомление о таймауте его запроса).

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

[sergek]

Складывать запросы от клиентов в БД - очень плохая идея. Выполненный запрос никому уже не нужен...

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

[Hellraiser]

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

[Bepec]

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

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