Добрый день! Подскажите, правильно ли я понял алгоритм формитрования блоковых запросов? 1. МРВ проходит по базе каналов, находит канал с дополнением, устанавливает его как канал-образец(Канал_0). 2. МРВ берет следующий канал с тем же дополнением (Канал_1) и вызывает zCompare_xxx ia0=Канал_0, ia1=Канал_1, count=1. 3. Я в zCompare_xxx проверяю два младших байта удаленного адреса для этих каналов, и другие свои условия: например, являются ли адреса запрашиваемых значений смежными. 4. Если условия соблюдаются, то я возвращаю из zCompare_xxx не ноль (например, count). 5. МРВ устанавливает каналу Канал_1 принадлежность к блоку с каналом-образцом Канал_0. Получили блок из двух каналов. 6. МРВ берет следующий канал с тем же дополнением (Канал_2) и вызывает zCompare_xxx ia0=Канал_0, ia1=Канал_2, count=2. 7. Повторение пункта 3. Например условия не соблюдаютя, возвращаю ноль. 8. МРВ проходит дальше по базе каналов, находит канал с дополнением, устанавливает его как канал-образец(Канал_1). 9. МРВ берет следующий канал с тем же дополнением (Канал_2) и вызывает zCompare_xxx ia0=Канал_1, ia1=Канал_2, count=1. 10. Переход к пункту 3.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. МРВ сам выбирает для проверки группового запроса только те каналы, которые имеют одинаковые значения атрибутов I0 (два младших байта). Поэтому в драйвере их проверять не надо. Надо проверять остальные байты удаленного адреса.
2. При выделении канала-образца МРВ обегает ВСЮ базу каналов (все каналы, вызывающие этот драйвер и удовлетворяющие п.1). Получение на одной из попыток отказа от включения канала в групповой запрос не прерывает процесса обегания по данному каналу-образцу.
Posted by ddkel (Участник № / Member № 4120) on :
Пункт 2 все же не соответствует действительности: как только из zCompare возвращается ноль, при следующем вызове zCompare ia0 содержит адрес следующего за Канал_0 подходящего канала, в независимости от того, попал этот канал (в моем вопросе Канал_1) в блок к какому-либо каналу-образцу (в моем вопросе Канал_0) или нет.
Posted by Nico (Участник № / Member № 5342) on :
zCompare в начальный момент вызывается для каждого канала!!! zCompare в стд режиме вызывается для группы каналов
в расширенном режиме t11(у zCompare 6 параметров) стд вызовы от начальных отличаются значением первого параметра
Posted by ddkel (Участник № / Member № 4120) on :
Господин Nico, прошу Вас внимательно читать вопрос, а не бросаться демонстрировать знание документации. В моем вопросе нет утверждений, что zCompare вызывается не для каждого канала, наоборот для некоторых каналов она вызывается больше одного раза. Да и разница между ТСОМ5 и ТСОМ6 в руководстве пользователя описана довольно внятно, но не имеет никакого отношения к рассматриваемому вопросу.
Posted by ddkel (Участник № / Member № 4120) on :
Уточню еще раз по п.2: МРВ дойдя до конца базы каналов, в качестве канала-образца берет Канал_1, уже попавщий в блок с Канал_0. Т.о. если у нас с Канал_0 блок из пяти каналов, то с Канал_1 у нас получится блок из четырех каналов, с Канал_2 - из трех, и так до конца блока. И каждый канал из первого блока будет инициатором блоковых запросов, с разным количеством каналов. Т.е. я хочу спросить, правильно ли то, что канал, уже попавший в блоковый запрос, продолжает участвоввать в формировании блоковых запросов и как часть блока и как канал-образец. Отправлю Вам на hotline@adastra.ru Проект ТМ6 с двумя блоками по пять каналов, проект MVS08Expr c t11s30.dll обрезанной до zCompare с выводом в окно сообщений параметров передаваемых в эту функцию монитором, будет желание, можете запустить, посмотреть.Дополнительно попросил бы Вас прокоментирвать изменение ia0.c[5], которое принимает значения count.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
"МРВ дойдя до конца базы каналов, в качестве канала-образца берет Канал_1, уже попавщий в блок с Канал_0. " - это действительно так.
По спецификации TCOM5 ia0.c[5] действительно принимает значения count.
У нас нет возможности анализировать драйверы пользователей.
Posted by Nico (Участник № / Member № 5342) on :
"Пункт 2 все же не соответствует действительности: как только из zCompare возвращается ноль, при следующем вызове zCompare ia0 содержит адрес следующего за Канал_0 подходящего канала, в независимости от того, попал этот канал (в моем вопросе Канал_1) в блок к какому-либо каналу-образцу (в моем вопросе Канал_0) или нет. "
Posted by ddkel (Участник № / Member № 4120) on :
Спасибо за ответы. Получается использовать ia0.c[5]для анализа принадлежности к блоку нельзя. Переделал все на ТСОМ6. Осталось придумать как отсечь вторичные блоки.
Posted by ddkel (Участник № / Member № 4120) on :
При двух группах по пять каналов получается следующая картина. Из zCompare для каналов уже вошедших в блок при повторном их опросе возвращаю 0, и получаю два запроса по пять значений, и восемь запросов по одному значению (исключатся каналы-образцы, т.к. для них возвращаемое значение было не ноль). Т.е. эту ошибку в работе МРВ обойти в zCompare невозможно; считаю этот случай ошибкой, т.к. не вижу ни одного практического применения вторичного опроса уже вошедших в блок каналов, и ошибка, видимо, не устранима - нашел те же вопросы на форуме от 27 07 2006 года. Да и для ТСОМ5 - порча значения ia0.c[5] приводит к невозможности использования этого интерфейса если в удаленном адресе используется шестой байт (зачем передавать значение count в двух разных переменных?).
[ 06.06.2013, 09:20: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Практические случаи реализации неполных групповых запросов существуют. Заложенный алгоритм реализации групповых запросов позволяет реализовать неполный групповой запрос при отсутствии корректного ответа на полный групповой запрос. При достоверном обмене неполные групповые запросы не реализуются. Алгоритм корректироваться не будет.
Для реализации доступа пользователя к ia0.c[5] и использования дополнительных строковых параметров запроса (ext_data) следует использовать TCOM6.
