• Запросы «lookup» для разрешения IRC-IoT адресов

Существует единственный тип объекта (Object Type) для запроса на разрешение IRC-IoT адресов, это: "lookup", такой объект может включать в себя один или два «Datum» двух разных подтипов, в зависимости от их названия:

1. "a" address (direct) – прямой запрос на разрешение IRC-IoT адреса
2. "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 робота сочтёт необходимым, он может ответить на недопустимый запрос соответствующей ошибкой, либо при большом числе запросов вовсе проигнорировать эти запросы, отвечая только доверенным роботам и системам.