•
Запросы «lookup» для разрешения IRC-IoT адресов
Существует единственный тип объекта (Object Type) для запроса на разрешение
IRC-IoT
адресов, это: "lookup", такой объект может включать в себя один или два
«Datum» двух разных подтипов, в зависимости от их названия:
- "a" address (direct) – прямой запрос на разрешение IRC-IoT адреса
- "r" (reverse) – обратный запрос на формирование IRC-IoT адреса
Каждый такой «Datum» сам по себе является отдельным запросом.
Прямой запрос состоит из одной строки – комбинированного адреса
IRC-IoT,
обратный запрос представляет собой «Datum», структура и набор полей
в котором, определяется исходя из названия первого присутствующего в нем поля.
В случае, если в одном сообщении присутствуют запросы двух
подтипов («a» и «r»), они объединяются
в
JSON массив из двух
элементов. Если же передается несколько запросов одного подтипа,
то они так же объединяются в отдельный
JSON массив внутри
вышестоящего «Datum». Для передачи одного запроса одного
типа массив не требуется.
Пример одиночного прямого запроса на разрешение
IRC-IoT
адреса:
{ *** Container ***, "ot":"lookup", "a":{"a1":"@NSK"} }
Пример группового запроса, содержащего шесть адресов для
разрешения, три из которых являются прямыми, а три обратными:
{ *** Container ***, "ot":"lookup",
[
"a": { [ "a1":"@NSK",
"a2":"@BERDSK/@LELYUHA",
"a3":"@BERDSK/@LELYUHA/@D3/PIN@KV33" ] },
"r": { [ "d1":{"ip4":"109.175.75.75"},
"d2":{"ip6":"2001:450:25:333::2"},
"d3":{"geo":{"country":"RU", "city":"Berdsk", "lang":"English"}} ] }
]
}
Ответ от сервиса распознавания адресов формируется в виде отдельного
IRC-IoT
сообщения, поле «ot» (Object Type) которого содержит строку:
"
answer".
Структура данного сообщения формируется по тем же принципам, что и
сообщения с запросом на разрешение адреса, за исключением ситуаций,
когда в ходе разрешения адреса возникает ошибка. Ответы на запросы
сохраняют нумерацию и порядок следования друг за другом, тот же, что
и в сообщении с запросом, однако тип меняется на противоположный,
ответ на запрос типа "a" имеет тип "r", а на запрос типа "r" тип "a".
В случае, если на один запрос имеется несколько ответов, то в
соответствующем ответу месте сообщения формируется массив из
нескольких ответных строк для ответа. Либо в виде строк для типа "a",
либо в виде объектов «Datum» для ответов типа "r".
•
Поисковые запросы «search» для сопоставления ячеек комбинированного адреса
Помимо запросов "
lookup", служащих для сопоставления комбинированного адреса
с логическими адресами оборудования, использующего для своей работы разные протоколы, в
протоколе
IRC-IoT предусмотрены
поисковые, уточняющие, запросы "
search", для формирования полного
комбинированного адреса. Только полностью сформированный комбинированный адрес может
гарантировать правильный ответ при подаче запросов "
lookup".
Приведенный ниже поисковой запрос "
search" запрашивает у противоположной
стороны список оборудования, расположенного по указанному физическому адресу размещения:
{ *** Container ***, "ot":"search", "s":{"s1":"/@NSK/@IVANOVA31/*@KV55"} }
В приведенном (возможном) ответе перечислены четыре устройства в виде JSON массива:
{ *** Container ***, "ot":"answer",
[
"a1": "SamsungTV",
"a2": "ESP8266-1",
"a3": "ESP8266-2",
"a4": "BlnkSP3S"
]
}
Например, ответ "a1", исходя из запроса, на самом деле, формирует уточнённый адрес вида:
"/@NSK/@IVANOVA31/SamsungTV@KV55"
Имея данный, полностью сформированный комбинированный адрес, можно
запрашивать физические параметры подключения конкретного устройства,
при помощи запроса типа "
lookup".
Ниже приведен другой запрос, при помощи которого, робот пытается
выяснить, в какой квартире находится устройство с названием «BlnkSP3S»:
{ *** Container ***, "ot":"search", "s":{"s1":"/@NSK/@IVANOVA31/BlnkSP3S@*"} }
На что, может быть получен ответ, означающий, что устройство расположено в квартире номер 55:
{ *** Container ***, "ot":"answer", [ "a1": "@KV55" ] }
Обратите внимание, что стандарт определяет только принципы разрешения
адресов, а кодификация адреса в виде конкретных названий, полностью лежит на
интеграторе
IRC-IoT
сети, либо на автоматической системе, создающей эту сеть.
Наличие обеих частей, до и после символа "@", в каждой из ячеек комбинированного
адреса, не обязательно для
GRS
сервиса.
Другой пример. Стекируемый коммутатор Cisco или Huawei. Расположен своими
отдельными частями в разных зданиях, например с именами "IVANOVA31" и "IVANOVA33".
Между этими домами проложено специальное оптическое волокно. Но, логически
коммутатор имеет всего один IP адрес. В таком случае, на запрос о местоположении
коммутатора может быть выдано несколько адресов размещения.
В качестве примера, можно привести такой запрос:
{ *** Container ***, "ot":"search", "s":{"s1":"/@NSK/CiscoStack88@*"} }
На что, исходя из приведённых условий, можем получить следующий ответ:
{ *** Container ***, "ot":"answer",
[
"a1": "@IVANOVA31",
"a2": "@IVANOVA33"
]
}
Ответ на поисковые запросы "
search" не гарантирован, и зависит от
политики безопасности сегмента
IRC-IoT
сети и конкретного робота. В случае, если автор
IRC-IoT
робота сочтёт необходимым, он может ответить на недопустимый запрос соответствующей
ошибкой, либо при большом числе запросов вовсе проигнорировать эти запросы, отвечая
только доверенным роботам и системам.