Есть некое устройство. Подключается к компьютеру через COM или USB.
Протокол обмена:
Компьютер посылает запрос — устройство присылает ответ. В случае ошибки, ответ может и не прийти.
При некоторых событиях устройство может послать сообщение компьютеру само, без запроса.
Пока я использую самую примитивную реализацию: посылаю запрос и некоторое время жду ответа. В первом приближении это работает, но валится, если устройство само пришлет сообщение.
Хочется сделать более надежную реализацию. Мне это видится как-то так:
Две очереди: посланных и принятых сообщений. Функция, которая формирует из них третью очередь — пар запрос-ответ. Причем, в третьей очереди могут быть и неполные пары: запрос без ответа, и ответ без запроса.
Принципы спаривания сообщений:
1) По времени. Ответ должен прийти в течение некоторого промежутка времени после отправления запроса.
2) По смыслу. Есть функция, определяющая, может ли данное сообщение быть ответом на данный запрос.
Не хочется изобретать велосипед. Наверняка есть и теория всего этого дела, и готовые библиотечные реализации, и open-source программы. Подскажите, пожалуйста, куда копать. Ссылки, книги, ключевые слова для поиска...
Здравствуйте, todritab, Вы писали:
T>Есть некое устройство. Подключается к компьютеру через COM или USB.
T>Протокол обмена: T>Компьютер посылает запрос — устройство присылает ответ. В случае ошибки, ответ может и не прийти. T>При некоторых событиях устройство может послать сообщение компьютеру само, без запроса.
T>Пока я использую самую примитивную реализацию: посылаю запрос и некоторое время жду ответа. В первом приближении это работает, но валится, если устройство само пришлет сообщение.
T>Хочется сделать более надежную реализацию. Мне это видится как-то так: T>Две очереди: посланных и принятых сообщений. Функция, которая формирует из них третью очередь — пар запрос-ответ. Причем, в третьей очереди могут быть и неполные пары: запрос без ответа, и ответ без запроса.
T>Принципы спаривания сообщений: T>1) По времени. Ответ должен прийти в течение некоторого промежутка времени после отправления запроса. T>2) По смыслу. Есть функция, определяющая, может ли данное сообщение быть ответом на данный запрос.
Мне кажется, что все плохо именно из-за того, что устройство может послать сообщение "внезапно" — т.е. по сути образуется второй "обратный" поток данных.
ИМХО или делать для обратных сообщений отдельный поток данных или различать как-то "прямой" и "обратный" поток данных... Ну, например префиксами какими-то.
Здравствуйте, todritab, Вы писали:
T>Есть некое устройство. Подключается к компьютеру через COM или USB.
T>Протокол обмена: T>Компьютер посылает запрос — устройство присылает ответ. В случае ошибки, ответ может и не прийти. T>При некоторых событиях устройство может послать сообщение компьютеру само, без запроса.
А можно ли по ответу определить на что был запрос? Если да, то имеет смысл разбирать все ответы (отдельный цикл приема), а там где время ответа критично — выставлять признаки что ожидается ответ на такой-то запрос.
Конечно, хорошо было бы, если б запрос содержал более-менее уникальный ID, и ответ на него содержал бы этот же ID. Но в протоколе этого нет...
По ответу нельзя однозначно определить запрос. Глядя на запрос и на ответ, можно сказать, что данный ответ {НАВЕРНЯКА МОЖЕТ}, {МОЖЕТ}, или {НИКАК НЕ МОЖЕТ} относиться к данному запросу.
То есть, запросто может возникнуть ситуация, когда ответ будет подходить к нескольким запросам. В этом случае, наверное, нужно подождать. Возможно, появятся сообщения с однозначно определенными ответами и все прояснится. Или наоборот, никаких сообщений не будет, пройдут таймауты, старое забудется и можно будет повторить запрос.
Наверняка все эти алгоритмы давно придуманы и разжеваны. Где бы об этом почитать?
Здравствуйте, todritab, Вы писали:
T>Наверняка все эти алгоритмы давно придуманы и разжеваны. Где бы об этом почитать?
А более точно описание алгоритма работы устройства есть? Также уточните, есть возможность корректировки протокола обмена?
