RTIO（Real Time Input Output Service for IoT）

RTIO提供设备上云的端到端解决方案，主要包括设备接入、设备代理、后端服务代理等功能：

用户端使用HTTP GET、POST方法通过RTIO控制和实时观察设备（通常用户端下发指令、观察设备状态）
设备通过GET、POST接口访问RTIO代理的资源（通常设备端获取服务端资源、上报事件）
用户可访问NAT网络后的设备

                 native │ could
                        │     ┌───────┐     ┌──────────┐
 ┌──────────┐ tcp/tls   │     │       ├─────► device   │
 │ device   ├───────────┼─────►       │     │ verifier │
 └──────────┘           │     │       │     └──────────┘
                        │     │ RTIO  │
 ┌──────────┐ http/https│     │       │     ┌──────────┐
 │ user     ├───────────┼─────►       │     │ device   │
 └──────────┘           │     │       ├─────► services │
  phone/web/pc...       │     └───────┘     └──────────┘

特点

REST-Like模型，其参考RESTFul模型
用户端通过HTTP访问设备，无需集成SDK
用户端通过HTTP即可实时观察设备（非轮询）
解耦资源实现和资源调用者（以URI标识不同资源或能力，无topic耦合）
单节点支持百万连接（压测报告）

为什么创建RTIO

RTIO简化设备接入云端开发。设备也是服务资源的提供者，RTIO采取REST-Like模型，使设备端开发具有和WEB服务开发相似的体验和高效。主要有以下优势：

以URI标识不同资源或能力，比如设备提供V2/V3接口，方便设备资源或能力迭代
通过GET、POST和ObGet（Observe-GET）等方法交互，流程更简单（相比MQTT减少一半以上交互，可参考FQA部分）
解耦资源实现和资源调用者，可使用工具独立测试（类似使用curl/postman工具验证WEB服务接口）

REST-Like模型，这里指类似REST模型，但不以HTTP协议作为底层协议，模型提供了GET和POST方法和ObGET（Observe-GET，观察者模式）等方法。

RTIO交互示例可参考下文RTIO和MQTT服务交互比较。

编译和运行

环境需要安装golang（1.20版本以上）和make工具。

git clone https://github.com/guowenhe/rtio.git
cd rtio
make

成功编译后，out目录下会生成执行文件，主要文件如下，rtio为服务端，printer为设备端。

$ tree out/
out/

├── examples
│   ├── printer
│   
├── rtio

运行示例，启动rtio服务（可通过-h参数查看帮助）。

$ ./out/rtio -disable.deviceverify -disable.deviceservice -log.level=info
INF cmd/rtio/rtio.go:77 > rtio starting ...

另一终端启动设备，模拟打印机。

$ ./out/examples/printer
INF internal/deviceaccess/access_client/devicesession/devicesession.go:675 > serving

另一终端模拟用户端，下达开始打印指令。

$ curl -X POST "http://127.0.0.1:17317/cfa09baa-4913-4ad7-a936-2e26f9671b04/post_handler" -d '{"uri":"/printer/action","id":12667,"data":"c3RhcnQ="}'
{"id":12667,"code":"CODE_OK","data":"cHJpbnQgc3RhcnRlZA=="} #

模拟用户端，持续获取打印进度。

$ curl -X GET "http://127.0.0.1:17317/cfa09baa-4913-4ad7-a936-2e26f9671b04/obget_handler?uri=%2Fprinter%2Fstatus&id=12334&data=MTIzNDU%3D"
{"result":{"id":12334,"fid":0,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgNDUl"}}
{"result":{"id":12334,"fid":1,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgNDgl"}}
{"result":{"id":12334,"fid":2,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgNTIl"}}
...
{"result":{"id":12334,"fid":18,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgOTEl"}} # data部分base64解码后：printing 91%
{"result":{"id":12334,"fid":19,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgOTQl"}} 
{"result":{"id":12334,"fid":20,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgOTgl"}}
{"result":{"id":12334,"fid":21,"code":"CODE_CONTINUE","data":"cHJpbnRpbmcgMTAwJQ=="}} # data部分base64解码后：printing 100%
{"result":{"id":12334,"fid":22,"code":"CODE_TERMINATE","data":""}}

设备端集成说明

设备端代码，handler实现：

func handlerAction(req []byte) ([]byte, error) {
  log.Info().Str("req", string(req)).Msg("") 
  return []byte("print started"), nil
}

func handerStatus(ctx context.Context, req []byte) (<-chan []byte, error) {
  log.Info().Str("req", string(req)).Msg("")
  respChan := make(chan []byte, 1)
  go func(context.Context, <-chan []byte) {
  for {
    select {
    ...
    case <-t.C:
      respChan <- []byte("printing " + strconv.Itoa(progress) + "%")
    }
  }(ctx, respChan)
  return respChan, nil
  }
}

设备端代码，给URI注册handler：

session := ds.NewDeviceSession(conn, deviceID, deviceSecret)
 ...
 // URI: /printer/action 0x44d87c69
 session.RegisterPostHandler(0x44d87c69, handlerAction)
 // URI: /printer/status 0x781495e7
 session.RegisterObGetHandler(0x781495e7, handerStatus)

备注：

设备集成具体步骤参见设备SDK。
GET/POST每次交互都带有URI标识，为压缩URI数据量，设备和RTIO服务交互过程采用4字节的哈希摘要（CRC32）通信，可使用rtio-urihash工具计算。
用户端Javascript可参考：user.html。

设备SDK

rtio-device-sdk-go 支持Golang

项目进展

目前完成设备端到服务端接入和Demo示例，rtio核心部分：

HTTP远程调用设备端资源（Get、Post、ObGet）
设备端调用后端服务资源（Get、Post）

FQA

RTIO和MQTT服务有何不同？

他们都能与NAT后面的设备通信，MQTT为发布订阅模型，是多对多的模型，RTIO是点对点模型。

点对点通信场景中，MQTT通常需要定义一对topic（*_req和*_resp）来实现请求和响应，而这对topic相关的处理函数（Handler）耦合在两个系统中。RTIO通过URI标识不同资源或能力，解耦资源实现和资源调用者。
什么场景选择点对点通信？U2M（User To Machine）选择哪种模型更合适？

“点对点通信”为两台设备间通信，“多对多通信”即多台设备间通行。“多对多”通信有多种实现模型，这里主要对比MQTT的“发布订阅”模型。

U2M为用户端（比如手机）设备控制IoT设备，是典型的点对点通信。如果采用发布订阅作为通信模型，也可实现对IoT设备控制。但相比点对点通信会复杂许多，可参考下文“RTIO和MQTT服务交互比较”。

另外，一个用户控制多台IoT设备，点对点通信是否适用？如果IoT设备间不进行复杂的交互（比如10台打印机之间没交互），这里用户相当于批量的对打印机控制，仅增加批量的控制逻辑（比如循环对10台打印机处理）即可，该场景点对点模型仍比发布订阅模型交互简单。
RTIO名字含义？

RTIO - Real Time Input Output。“实时输入输出”，这里的“实时”指在期望的时间完成通信，否则返回超时错误。通过同步通信方式使IoT（特别是远程控制IoT设备）开发更简单。

RTIO和MQTT服务交互比较

RTIO和MQTT服务交互比较，请求到云端获取version列表

sequenceDiagram
    Title: get versions over mqtt
    participant device as mqtt-device
    participant  broker as mqtt-broker
    participant  app as app-server
    
    app ->> broker: SUBSCRIBE toppic: $diviceid_get_versins_req
    broker -->> app: SUBACK
    device ->> broker: SUBSCRIBE toppic: $diviceid_get_versins_resp
    broker -->> device: SUBACK

    device ->> broker: PUBLISH toppic: $diviceid_get_versins_req
    broker -->> device: PUBACK

    broker ->> app: PUBLISH toppic: $diviceid_get_versins_req
    app -->> broker: PUBACK

    app ->> app: query versions
    app ->> broker: PUBLISH toppic: $diviceid_get_versins_resp
    broker -->> app: PUBACK

    broker ->> device: PUBLISH toppic: $diviceid_get_versins_resp
    device -->> broker: PUBACK

sequenceDiagram
    Title: get versions over rtio
    participant device as rtio-device
    participant  rtio as rtio-server
    participant  app as app-server(resource-server)

    rtio ->> rtio: auto discover resource and registry
    
    device ->> rtio: GET /resource/versins
    rtio ->> app: GET
    app -->> rtio: versions
    rtio -->> device: versions

用户控制设备开关

sequenceDiagram
    Title: power on over mqtt
    participant device as mqtt-device
    participant  broker as mqtt-broker
    participant  app as app
    
    app ->> broker: SUBSCRIBE toppic: $diviceid_led_power_resp
    broker -->> app: SUBACK
    device ->> broker: SUBSCRIBE toppic: $diviceid_led_power_req
    broker -->> device: SUBACK

    app ->> app: user power on
    app ->> broker: PUBLISH toppic: $diviceid_led_power_req
    broker -->> app: PUBACK

    note over app,broker : means brocker successfully received not device

    broker ->> device: PUBLISH toppic: $diviceid_led_power_req
    device -->> broker: PUBACK

    device ->> device: led power action

    device ->> broker: PUBLISH toppic: $diviceid_led_power_resp
    broker -->> device: PUBACK
    

    broker ->> app: PUBLISH toppic: $diviceid_led_power_resp
    app -->> broker: PUBACK

sequenceDiagram
    Title: power on over rtio
    participant device as rtio-device
    participant  rtio as rtio-server
    participant  app as app

    app ->> app: user power on
    app ->> rtio: POST  $device_name/led_power
    note right of app : could set timeout
    rtio ->> device: POST /led_power
    device ->> device: led power action
    device -->> rtio: led_power status
    rtio -->> app: led_power status

观察者模式（MQTT服务没有此模式）

sequenceDiagram
    Title: rtio observation
    participant device as rtio-device
    participant  rtio as rtio-server
    participant  app as app

    app ->> app: observe progress
    app ->> rtio: OBGET  $device_name/progress
    rtio ->> device: OBGET /progress

    device -->> rtio: 20%
    rtio -->> app:  20%

    device -->> rtio: 30%
    rtio -->> app:  30%
    note over app,device : The observation can be terminated by device or app
    device -->> rtio: 100%
    rtio -->> app:  100%

Name		Name	Last commit message	Last commit date
Latest commit History 32 Commits
cmd/rtio		cmd/rtio
docs		docs
examples		examples
internal		internal
pkg		pkg
scripts		scripts
.gitignore		.gitignore
AUTHORS		AUTHORS
LICENSE		LICENSE
Makefile		Makefile
README.md		README.md
go.mod		go.mod
go.sum		go.sum

License

guowenhe/rtio

Folders and files

Latest commit

History

Repository files navigation

RTIO（Real Time Input Output Service for IoT）

特点

为什么创建RTIO

编译和运行

设备端集成说明

设备SDK

项目进展

FQA

RTIO和MQTT服务交互比较

About

Topics

Resources

License

Stars

Watchers

Forks

Languages