ITMP

Part 0: Overview

0.1 Introduction

The Internet of Thinks Messaging Protocol is open Internet protocol for inter thinks messaging. ITMP consist of three important components: discovering, remote procedure calling, messaging (pub-sub), in comparing with competitors ITMP is compact, simple, extensible, robust protocol.

0.1.1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in IETF
RFC2119.

0.2 Conformance

ITMP defines a wire level protocol. ITMP does not define a wire-level distinction between "clients" and "servers", the protocol is symmetric. It is expected and encouraged that implementations of ITMP will have different capabilities.

A conformant implementation MAY perform protocol negotiation, and then parse, process, and produce frames in accordance with the format and semantics.

Conformant implementations MUST NOT require the use of any extensions defined outside this document in order to interoperate with any other conformant implementation.

Part 1 of this document defines the type system and type encodings that every conformant implementation MUST implement.

Part 2 defines the peer-to-peer transport protocol which operates over TCP and UDP or Serial Line. Every conformant implementation of TMP over TCP MUST implement Part 2. Part 2 admits behaviors that might not be appropriate for every implementation. For example a “client library” might not allow for its communication partner to spontaneously attempt to initiate a connection and request messages. Where an implementation does not allow for a behavior the implementation MUST respond according to the rules defined within Part 2 of the specification.

Part 3 of this document defines the ITMP Messaging Layer. Every conformant implementation which processes messages MUST implement this part of the specification. Some implementations might not process messages (for example, an implementation acting as a “router” which looks only at the routing information carried by the ITMP Transport layer). Such implementations do not actively implement Part 3, but MUST NOT act in ways which violate the rules of this part of the specification. The Messaging layer admits behaviors that might not be appropriate for all implementations (and within an implementation all behaviors might not be available for all configurations). Where a behavior is not admitted, the implementation MUST respond according to the rules defined within this specification.

Part 4 defines the requirements for transactional messaging. Transactional messaging defines two roles, that of the transactional resource and that of the transaction controller. A conformant implementation SHOULD be capable of operating in one of these roles but MAY be unable to operate in either (for instance a simplistic client library might have no ability to act as a transaction controller and would not be expected to act as a transactional resource).

It is RECOMMENDED that implementations designed to act as messaging intermediaries support the ability to act as a transactional resource. It is RECOMMENDED that implementations or re-usable libraries provide Application Programming Interfaces to enable them to act as transactional controllers. Where a behavior is not admitted, the rules defined in part 4 regarding responses to non-admitted behaviors MUST be followed.

Part 5 defines Security Layers to provide an authenticated and/or encrypted transport. Implementations SHOULD allow the configuration of appropriate levels of security for the domain in which they are to be deployed. Conformant implementations acting in the TCP server role are strongly RECOMMENDED to implement Part 5: section 5.2 (or Part 5: 5.2.1 Alternative Establishment). Implementations acting in the TCP server role are strongly RECOMMENDED to implement Part 5: section 5.3 and to support commonly used SASL mechanisms. In particular such implementations SHOULD support the PLAIN [RFC4616] and SCRAM-SHA1 [RFC5802] mechanisms.  Conformant implementations acting in the TCP client role SHOULD be capable of being configured to connect to an implementation in the TCP server role that is following the recommendations above.

Part 1: Types

1.1 Type System

The ITMP based mostly on JSON format and CBOR encoding and type system followed by those definition for interoperable data representation. ITMP values can be annotated with CBOR extension.

1.1.1 Primitive Types

The ITMP type system defines a standard set of primitive types for representing both common scalar values and common collections. The scalar types include booleans, integer numbers, floating point numbers, strings and binary data. The collection types include arrays(polymorphic), and maps.

1.2 Type Encodings

An ITMP uses JSON strings or CBOR binary encoded messages.

Part 2: Transport

2.1 Transport

2.1.1 Conceptual Model

An ITMP network consists of nodes connected via links. Nodes act as agents and can realize one or more roles. Actor is a node that implements RPC functions. Publisher is a node that produces events. Subscriber is a node that can receive events messages and react for its in some manner. Broker is a node that act as Subscriber for all Connected Publishers act as Publisher for Subscribers and connect one another.

2.1.2 Protocol Frames

The protocol consists of messages of frames all of them has same structure.

[<message type>,<id>,<name>,<parameters>,<options>]

where <message type> - integer number from 0 - 23 described int table 2.1

<id> - integer number initially chosen randomly and then increments any time new message sending. It prevent of messages doubles and allow correlate answer to question.

<name> - string denotes procedure to call or event name to emit or subscribe

<parameters> - array of function or event parameters or map of named values instead of position dependent values stored in array, can be committed if empty

<options> - map of named values extend parameters of calling method, can be committed if empty

 

  

Connection
0 [CONNECT,0,"ITMP10"] opened connection and make version negotiation
1 [CONNECTED,0,"ITMP10"] confirm connection and start communication
2 [ABORT,0,"",[503,"time out"]] terminate connection
3 [DISCONNECT,0,"",[503,"time out"]]  
Description
4 [GETDESCR,id,"name"] 6 - get description
5 [DESCR,id,"name",["name&int"]] 7 - description response
6 [DESCRERR,id,"name",[404,"not found"]] 8 - get - description error
     
RPC
8 [CALL,id,"name",[1,2]] 9 - call
9 [CALLCANCEL,id,"name"] 10 call cancel
10 [CALLRESP,id,"name",["ok","result"]] 11 - call response
     
12 [PROGRESS,id,"name",[2,"almost done"]] 12 call in progress
13 [CALLERR,id,"name",[503,"time out"]] 13 - call error
14    
15    
publish
16 [EVENT,id,"alarm",[32,"12:33"]] 14 - event
17 [EVENT_WITH_ACK,id,"alarm",[32,"12:33"]] 15 - event with acknowledge awaiting
18 [EVENTACK,id,"alarm"] 15 - event acknowledged
19 [EVENTNAK,id,"alarm",[500,"server busy"]] 16 - event not acknowledged
subscribe
20 [SUBSCRIBE,id,"alarm"] 17 - subscribe
21 [UNSUBSCRIB,id,"alarm"] 20 - unsibscribe
22 [CONFIRMED,id,"alarm",[503,"no memory"]] 18 - subscription confirmed19 - subscription not confirmed
23 [NOT CONFIRMED,id,"*",[503,"no memory"]]  
 
23 [KEEP_ALIVE,id,""] 23 - keep alive
     
     
     
     
     
     
     

 

2.2 Version Negotiation

Prior to sending any frames on a connection, each peer MAY start by sending a protocol header that indicates the protocol version used on the connection. In total this is an CONNECT message:

JSON: [CONNECT, 0, "ITMP10"]

CBOR: 83  00  00  66 49 54 4d 50 31 30 // 10 bytes

Any data appearing beyond the protocol header MUST match the version indicated by the protocol header. If the incoming and outgoing protocol headers do not match, both peers MUST close their outgoing stream and SHOULD read the incoming stream until it is terminated.

The ITMP peer which acted in the role of the TCP client (i.e. the peer that actively opened the connection) MUST immediately send its outgoing protocol header on establishment of the TCP connection. The ITMP peer which acted in the role of the TCP server MAY elect to wait until receiving the incoming protocol header before sending its own outgoing protocol header. This permits a multi protocol server implementation to choose the correct protocol version to fit each client.

Two ITMP peers agree on a protocol version as follows (where the words “client” and “server” refer to the roles being played by the peers at the TCP connection level):

 When the client opens a new socket connection to a server, it MUST send a protocol header with the client’s preferred protocol version.
 If the requested protocol version is supported, the server MUST send its own protocol header with the requested version to the socket, and then proceed according to the protocol definition.
 If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket.
 When choosing a protocol version to respond with, the server SHOULD choose the highest supported version that is less than or equal to the requested version. If no such version exists, the server SHOULD
respond with the highest supported version.

PART 3. Messaging

3.1 Connect

3.1.1.  CONNECT

Sent by a Client to initiate opening of a ITMP session to a Router attaching to a Realm.

       [CONNECT, Realm|uri, Options|dict]

3.1.2.  CONNECTED

   Sent by a Server to accept a Client.  The ITMP session is now open.

       [CONNECTED, Session|id, Options|dict]

3.1.3.  ABORT

   Sent by a Peer*to abort the opening of a ITMP session.  No response is expected.

       [ABORT, Reason|uri, Options|dict]

3.1.4.  DISCONNECT

   Sent by a Peer to close a previously opened ITMP session.  Must be echo'ed by the receiving Peer.

       [DISCONNECT, Reason|uri, Options|dict]

 

 

6.4.1.5.  ERROR

   Error reply sent by a Peer as an error response to different kinds of
   requests.

       [ERROR, REQUEST.Type|int, REQUEST.Request|id, Details|dict,
           Error|uri]

       [ERROR, REQUEST.Type|int, REQUEST.Request|id, Details|dict,
           Error|uri, Arguments|list]

       [ERROR, REQUEST.Type|int, REQUEST.Request|id, Details|dict,
           Error|uri, Arguments|list, ArgumentsKw|dict]

If the server cannot parse the protocol header, the server MUST send a valid protocol header with a supported protocol version and then close the socket.
Note that if the server only supports a single protocol version, it is consistent with the above rules for the server to send its protocol header prior to receiving anything from the client and to subsequently close the socket if the client’s protocol header does not match the server’s.

Based on this behavior a client can discover which protocol versions a server supports by attempting to connect with its highest supported version and reconnecting with a version less than or equal to the version received back from the server.

 

3.2 Description

3.2.1.  GETDESCR

Sent by a Client to get information about method, event or whole node.

       [GETDESCR, id|int, name|uri, Options|dict]

3.2.2.  DESCR

   Sent by a Node to inform about event or function.

       [DESCR, id|int, name|uri, [description|string] Options|dict]


<field description> ::= <name><description><signature>
<name> ::= string
<signature> ::= <interface> | <func> | <event> | <container>
<interface> ::= ’:’ [ <interface name> [ , <interface name> ] ]
<interface name> ::= string
<container> ::= ’*’ [ <interface name> [ , <interface name> ] ]
<func> ::= ’&’ <return type list> [ ‘(‘ <argument type list> ’)’ ]
<event> ::= ’!’ <type list>
<return type list> ::= <type list>
<argument type list> ::= <type list>
<type list> ::= [ <type> [ , <type> ] ]
<type> ::= <simple type> | '['<type list>']' | '{' <prop name> [ '?' ] : <type> [ , <prop name> : <type> ] '}'
<simple type> ::= <type char> [<description>]
<description>::='’' [<name>] [<version>] [<UniqueId>] [<units>] [<variants>] [<manufacturer>] '’'
<version>::=’%’ string
<UniqueId>::=’#’ string
<units> ::= '$' string
<variants> ::= '<' <value> [ , <value> ] '>'
<manufacturer> ::= '@' string
<type char> ::= i | s | b | f | B | N | Q | I | U | X | T | F | D | S

simple type JSON and CBOR encoded

i integer
s  UTF-8 string
b boolean
f  floating point number

fixed types JSON BASE64 string or CBOR byte array encoded as sequence (for small controllers without complex encoders)

B  8-bit unsigned integer (byte)
N  16-bit signed integer
Q  16-bit unsigned integer
I  32-bit signed integer
U  32-bit unsigned integer
X  64-bit signed integer
T  64-bit unsigned integer
F  single-precision floating point (IEEE 754)
D  double-precision floating point (IEEE 754)
S  UTF-8 string with length prefix

any sequence of primitive typed values encoded as byte array or base64 encoded string for json

3.3 Call

 

 

3.4 Subscribe

 

 

3.4 Publish

 

 

3.5 Keep alive

 

 

 

 

TCP Client TCP Server
======================================================
AMQP%d0.1.0.0 ------------->
<------------- AMQP%d0.1.0.0 (1)
... *proceed*
AMQP%d0.1.1.0 ------------->
<------------- AMQP%d0.1.0.0 (2)
*TCP CLOSE*
HTTP ------------->
<------------- AMQP%d0.1.0.0 (3)
*TCP CLOSE*
------------------------------------------------------
(1) Server accepts connection for: AMQP, protocol=0,
major=1, minor=0, revision=0
(2) Server rejects connection for: AMQP, protocol=0,
major=1, minor=1, revision=0, Server responds
that it supports: AMQP, protocol=0, major=1,
minor=0, revision=0
(3) Server rejects connection for: HTTP. Server
responds it supports: AMQP, protocol=0, major=1,
minor=0, revision=0
Figure 2.12: Version Negotiation Examples
Please note that the above examples use the literal notation defined in RFC 2234 [RFC2234] for non alphanumeric
values.
The protocol id is not a part of the protocol version and thus the rule above regarding the highest supported
version does not apply. A client might request use of a protocol id that is unacceptable to a server - for example,
it might request a raw AMQP connection when the server is configured to require a TLS or SASL security layer
(See Part 5: section 5.1). In this case, the server MUST send a protocol header with an acceptable protocol id
(and version) and then close the socket. It MAY choose any protocol id.
TCP Client TCP Server
======================================================
AMQP%d0.1.0.0 ------------->
<------------- AMQP%d3.1.0.0
*TCP CLOSE*
------------------------------------------------------
Server rejects connection for: AMQP, protocol=0,
major=1, minor=0, revision=0, Server responds
that it requires: SASL security layer, protocol=3,
major=1, minor=0, revision=0
Figure 2.13: Protocol ID Rejection Example
2.3 Framing
Frames are divided into three distinct areas: a fixed width frame header, a variable width extended header, and a
variable width frame body.
amqp-core-complete-v1.0-os
Standards Track Work Product Copyright
c OASIS Open 2012. All Rights Reserved.
29 October 2012
Page 36 of 124
PART 2. TRANSPORT 2.3 Framing
REQUIRED OPTIONAL OPTIONAL
+--------------+-----------------+------------+
| frame header | extended header | frame body |
+--------------+-----------------+------------+
8 bytes *variable* *variable*
Figure 2.14: Frame Layout
frame header The frame header is a fixed size (8 byte) structure that precedes each frame. The frame
header includes mandatory information necessary to parse the rest of the frame including
size and type information.
extended header The extended header is a variable width area preceding the frame body. This is an extension
point defined for future expansion. The treatment of this area depends on the frame type.
frame body The frame body is a variable width sequence of bytes the format of which depends on the
frame type.
2.3.1 Frame Layout
The diagram below shows the details of the general frame layout for all frame types.
+0 +1 +2 +3
+-----------------------------------+ -.
0 | SIZE | |
+-----------------------------------+ |---> Frame Header

 

 

 

Основная функция протокола обмен сообщениями для реализации передачи уведомлений, а также удаленного вызова функций.

Небольшие накладные расходы на передачу сообщений позволяют реализовать протокол на небольших контроллерах

1.1     Формат сообщения

Сообщение представляет собой пакет состоящий из заголовка, опций, адреса и данных

[message_type,id,name,data,options]

message type one of

   CHALLENGE: 4,
   AUTHENTICATE: 5,
0 - connect

1 - connected

2 - not connected

3 abort

4 - disconnect

5 - disconnected

6 - get description

7 - description response

8 - get - description error

9 - call

10 call cancel

11 - call response

12 call in progress

13 - call error

14 - event

15 - event acknowledged

16 - event not acknowledged

17 - subscribe

18 - subscription confirmed

19 - subscription not confirmed

20 - unsibscribe

21 - unsubscripted

22 - not unsubscripted

23 - keep alive

 

 id is number (unsigned id) it should start from any value (random) and should increment every time (it can be used to control double sending and lost packets)

 

 

name is string name (could be integer value for simplest implementations) of calling function emitted event and so on

 

data is array or map of arguments for calling function return value for returning and so on, data can be omitted if there is no options in message

 

options is map of additional values specific for that method, options can be omitted if there is empty map

 

 

 

 

message encoding:

JSON encoding, then transport is string based it is variant

CBOR encoding, then transport is binary based

 

Hello world message encoding

 

[7,14756,"","Hello world"]

JSON

CBOR

message "hello world" even without topic

[7,14756,"","Hello world"]

26 bytes

84 - array of 4 items
07 - integer value - 7
19 39 a4 integer value 14756
60 - empty string
6B 48 65 6c 6c 6f 20 77 6f 72 6c 64 - string "Hello world"

18 bytes

call the method relay.on without parameters

[4,4365,"relay.on"]

19 bytes

83 - array of 3 items
04 - integer value - 4
19 11 0d integer value 4365
68 72 65 6c 61 79 2e 6f 6e -  string "relay.on"

14 bytes

   

 

call e method

 

[4,4365,"relay.on"]

return

[5,4365,"relay.on"] or even [5,4365] // if function relay.on has no return value (void in c language)

[5,4365,"relay.on",true] or even [5,4365,null,true] // if function relay.on has boolean return value type

[6,4365,"relay.on",[4,"arguments omitted"]] or even [6,4365,null,[4,"arguments omitted"]] // if function relay.on can not be called because arguments should be passed

 

 

 

 

Заголовок

идентификатор сообщения

адрес(url)

данные

 

Заголовок занимает один байт

bit

octet

0

1

2

3

4

5

6

7

0

MTH

T

A

ML

MTH - Method

00 = LCP  (link control protocol)

01 = desc (announce when NON) empty url-get dev desc

10 = call (inform when NON)

11 = publ (NON or CON publication)

 

T

0 = NON non confirmable message

1 = CON confirmable request

2 = ACK normal response

3 = ERR error response

 

A

00 – no address present (point to point)

01 – Master to slave (slave address presented)

10 – slave to Master (slave address presented)

11 – desination and source address presented

 

ML

0 = no message id or in options

1 = message id is 1 bytes length

2 = message id is 2 bytes length

3 = message id is 4 bytes length

Метод определяет сообщение и смысл следующих бит.

LCP – сообщение относится к протоколу управления соединением (смотри соответствующий раздел).

Call – (аналог GET в REST идеологии) сообщение ITMP обеспечивающее удаленный вызов процедуры подписку на событие или список членов для индексатора или объекта

Desc – сообщение ITMP обеспечивающее получение информации об указанном URL

Publ – сообщение ITMP обеспечивающее возможность сообщить об асинхронном событии (от клиента к получателю, указывается урл события)

 

тип сообщения

NON – сообщение не требует подтверждения принимающей стороной

CON – сообщение требует подтверждения (или ответа с соответствующими данными)

ACK – сообщение ответ на CON сообщение - успех

ERR – сообщение ответ на CON сообщение - неуспех

длина идентификатора сообщения указана в заголовке

 

длина url может быть от 0 до 127 байт и указывается в одном байте

 

Данные в сообщении зависят от url для которого выполняется запрос и продолжаются до конца пакета.


 

 

1.2     Сообщения

1.2.1     Сообщение Call

В сообщении указывается URL требуемого действия, в payload параметры, для контроля повторной отправки и сопоставления запроса и ответа каждое сообщение помечается MessageID который увеличивается после отправки каждого сообщения.

Если при запросе биты T установлены в NON не предполагает ответ, если в запросе биты T установлены в CON – запрос подразумевает получение ответа (ACK или ERR) с тем- же url и MessageID что и в запросе

при ответе устанавливаются биты T равными ACK или ERR в зависимости от успешности выполнения запрашиваемого действия

1.2.2     Сообщение Desc (Description)

В сообщении указывается URL для которого требуется получить описание, payload должен быть пустым, для контроля повторной отправки и сопоставления запроса и ответа каждое сообщение помечается MessageID который увеличивается после отправки каждого сообщения.

Биты T установлены в CON – запрос подразумевает получение ответа (ACK или ERR) с тем- же url и MessageID что и в запросе

при ответе устанавливаются биты T равными ACK или ERR в зависимости от успешности выполнения запрашиваемого действия

1.2.3     Сообщение Publ (Publish)

В сообщении указывается URL возникновения события, payload содержит информацию о событии, для контроля повторной отправки и сопоставления запроса и ответа каждое сообщение помечается MessageID который увеличивается после отправки каждого сообщения.

Если необходимо получить подтверждение сообщения T устанавливается в CON иначе NON. при необходимости получить подверждение ожидается ответ  (ACK или ERR) с тем- же url и MessageID что и в запросе. оба ответа говорят о корректном получении сообщения и повторные отправки прекращаются.

1.2.4     Сообщения об ошибках

сообщение об ошибке содержит первым байтом код ошибки далее необязательное текстовое описание ошибки

Коды ошибок

+------+------------------------------+---------+

| Code | Description                  | encoded |

+------+------------------------------+---------+

| 1.02 | Processing                   |    12   |

| 4.00 | Bad Request                  |    40   |

| 4.01 | Unauthorized                 |    41   |

| 4.02 | Bad Option                   |    42   |

| 4.03 | Forbidden                    |    43   |

| 4.04 | Not Found                    |    44   |

| 4.05 | Method Not Allowed           |    45   |

| 4.06 | Not Acceptable               |    46   |

| 4.12 | Precondition Failed          |    4B   |

| 4.13 | Request Entity Too Large     |    4C   |

| 4.15 | Unsupported Content-Format   |    4F   |

| 5.00 | Internal Server Error        |    50   |

| 5.01 | Not Implemented              |    51   |

| 5.02 | Bad Gateway                  |    52   |

| 5.03 | Service Unavailable          |    53   |

| 5.04 | Gateway Timeout              |    54   |

| 5.05 | Proxying Not Supported       |    55   |

| 5.06 | call exception               |    56   |

+------+------------------------------+---------+

Задержка ответа

Если сервер не может немедленно ответить на запрос клиента (особенно в ситуации когда мастер-клиент управляет порядком запросов по шине к нескольким серверам) он может ответить сообщением Processing (12), тогда клиент должен через указанную задержку послать повторный запрос с тем же ID и получить задержанный ответ сервера.

1.3     Схема описания данных

при выполнении запроса get возвращается описание поля без указания имени (имя есть в поле url), при запросе call для получения списка полей отдается массив (вначале указывается количество полей, а затем сами поля) строк с описанием полей объекта.

<field description>::=<name><description><signature>

<name>::=string

<signature>::=<interface>|<func>|<event>|<container>

<interface>::=’:’[<interface name>[,<interface name>]]

<container>::=’*’[<interface name>[,<interface name>]]

<func>::=’&’<ret type list>[‘(‘<argument type list>’)’]

<event>::=’!’<type list>

<interface name>::=string

<ret type list>::=<type list>

<argument type list>::=<type list>

<type list>::=[<type>[,<type>]]

<type>::=<simple type>|a<simple type>

<simple type>::=<type char>[<description>]

<description>::='{'[<name>][<version>][<UniqueId>] [<units>][<variants>][<manufacturer>]'}'

<name>::=string

<version>::=’%’string

<UniqueId>::=’#’string

<units>::='$'string

<variants>::='['<value>[,<value>]']'

<manufacturer>::='@'string

<type char>::=b|n|q|i|u|x|t|N|Q|I|U|X|T|f|d|s

primitive types

b  8-bit unsigned integer (byte)

n  16-bit signed integer

q  16-bit unsigned integer

i  32-bit signed integer

u  32-bit unsigned integer

x  64-bit signed integer

t  64-bit unsigned integer

N  16-bit packed signed integer

Q  16-bit packed unsigned integer

I  32-bit packed signed integer

U  32-bit packed unsigned integer

X  64-bit packed signed integer

T  64-bit packed unsigned integer

f  single-precision floating point (IEEE 754)

d  double-precision floating point (IEEE 754)

s  UTF-8 string with length prefix

Examples

NSC duino{#1.0}:motor

 

addr&b

setpwm&b{status}(n{value[0..1024]})

 

DESCR "" responce

F01.100:apollo,upd{#1.0}

 

CALL "" responce

upd&(b)

frd&(i)

pwr&(b)

stat&b{status byte}

dev*fgdev

 

DESCR "dev" response

dev{extrenal bus devices}*fgdev

 

CALL "dev" response

 

num&b{devs number}

add&(s{element name})

del&(s{element name})

list&as{array of item names}

*fgdev

 

CALL "dev/*" response

 

stat&b{status byte}

act{execute action}&b{status byte}(b{action to execute[0=none,1=reset]})

 

DESCR "dev/num" response

 

{number of external devices connected}&b{devices number}

 

DESCR "dev/5" response

 

stat&b{status byte}

act{execute action}&b{status byte}(b{action to execute[0=none,1=reset]})

 

Интерфейс содержит сигнатуры методов, свойств, событий

функция это необходимое действие со списком параметров и списков возвращаемых значений описывается как

Свойство это объединение двух методов – чтения и записи, причем типы для чтения и записи совпадают, если в запросе присутствует поле данных то это операция записи а затем чтения в противном случае это операция чтения (когда поле данных в запросе пустое), при необходимости реализовать свойство, доступное только для записи, нужно определить функцию без возвращаемого параметра

Событие это извещение клиента об изменении состояния агента, событие сопровождается сопутствующими данными

Коллекция, именованный набор элементов имеющих общие интерфейсы

коллекция может поддерживать получение количества, списка элементов, а также операции по добавлению/удалению элементов. Эти операции должны быть сообщены по запросу Call для коллекции ели получение списка элементов в запросе CALL для коллекции не реализовано, последним элементом перечня методов должен быть метод * без имени подразумевающий что в коллекции есть элементы но их список недоступен (даже если на момент запроса количество элементов 0)

 

1.4     Примеры сообщений

Each device describing as object consist of variables, functions and events. Each variable, function and event has a type (for functions input and output, for events output), name, id, and tagged annotations

Get Device object Description

51                 get description

00                 message id=0

00                 get device description (no resource name)

encoded answer (32 bytes)

61                 descripttion answer

00                 message id=0

00                 description of device empty uri

 

1C                 description length

4d 4f 54 38 32 33  MOT823.112rack:mot{#1.0@NSC}

2e 31 31 32 72 61

63 6b 3a 6d 6f 74

7b 23 31 2e 30 40

4e 53 43 7d

Get field list

91                 call emty url command

01                 message id=1

00                 root with empty uri        

answer

A1                 answer

01                 message id=1

00                 root with empty uri

08 02 6c 57 01 57  url list = ["lW","W","3","4",

01 33 01 34 01 35  "5","6","7","info"]

01 36 01 37 04 69

6e 66 6f

Get field description

91                 get description command

02                 message id=2

02 6c 57           uri = "lW"                 

answer encoded

A1                 get description answer

02                 message id=2

02 6c 57           uri = "lW"

1c                 description length

26 62 7b 6c 65 76  “&b{level of Water$%[0..100]}”

65 6c 20 6f 66 20  function return one byte

57 61 74 65 72 24  that means water level in

25 5b 30 2e 2e 31  percents (from 0 to 100)

30 30 5d 7d

Get field description (4 bytes)

91                 get description command

03                 message id=3

01 57              uri = "W"                  

answer encoded (40 bytes)

A1                 get descripttion answer

03                 message id=3

01 57              uri = "W"                  

1d                 description length

7b 73 74 61 72 74  “{start watering}&

20 77 61 74 65 72  (b{time$ms})”

69 6e 67 7d 26 28

62 7b 74 69 6d 65

24 6d 73 7d 29

possible error answer encoded

B1                 get descripttion err answer

03                 message id=3

01 57              uri = "W"                  

44                 url not found

Publish Message

D2                 publish CON

00 00              message id=0 (two bytes)

08 31 32 2f 73 74

61 72 74           URL: "12/start"

 

46 7b              event data

Example answer

E2                 publish ACK

00 00              message id=0 (two bytes)

08 31 32 2f 73 74

61 72 74           URL: "12/start"

 

JSN Mini template designed by JoomlaShine.com