realglobe-inc / sugos Goto Github PK

View Code? Open in Web Editor NEW

9.0 9.0 0.0 1.17 MB

A high-level RPC framework to make remote controlling super easy.

License: Apache License 2.0

JavaScript 98.02% HTML 1.98%

sugos oss

sugos's Issues

チュートリアルを描く

What is SUGOS ?
Quick Start
Create Custom Module
Create Module Plugin
Create Custom Endpoint
Create Endpoint Plugin
Create Site project

SUGOS式関数共有のメリットについて

定義が簡素になる
機能をもとに設計できる
マイクロサービスとの相性が良い

これらのメリットはRest設計の抱える以下の問題の裏返しである。

RestはHTTPの文法が混ざって分かりにくい
Restはデータ構造が基準になので分かりにくい。

例えばOpenAPIに沿ってAPIを記述しようとすると、以下のような定義が必要になる

https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/json/petstore.json

「post」「201」といった、「HTTPの約束」という事前知識が必要で、かつ「Create」は「Post」、「Update」は「Patch」といった翻訳が必要になる。

また、Restはデータ構造を基準にするので、機能を実現するまでに、

「やりたいこと」がもたらす「結果」を考え、モデル構造を決める
「モデル構造」から逆算して、やりたいことを実装する

といったことが必要になる。

例えばECサイトで「買い物かごに入れる」という機能は「UserIdとItemIdを紐付けたCartレコードを新たに発行する」というデータ構造される。そして画面側の実装は「Cart」APIの実装から逆算して、「CartにPOST」するという関数を新たに定義することになる。

これは現在のWebサイトではごく一般的な実装ではあるが、モデルへの依存が大きいという問題を抱える。最初に適切なモデル設計ができれば良いのだが、ある程度複雑なシステムになると現実的には難しい。またモデル定義の変更の余波がとても大きいので、変化に弱いという欠点を抱える

一方、関数ベースの定義の場合は、HTTPの文法が混じらない分、定義が簡潔になる

https://github.com/realglobe-Inc/sugo-module-serialport/blob/master/lib/sugo_module_serialport.js#L215

以下のようなドキュメントの自動生成も用意である

https://github.com/realglobe-Inc/sugo-module-plen#methods

そして提供する機能からモデル構造を隠蔽できるので、変化に強くなる。
先ほどの例だと、「買い物かごに入れる」機能だけを提供することで、実際のモデル構造を画面側から隠蔽できる。

なお、機能基準のAPIという考え方は、実はREST登場以前にもあった。StrutsのActionなどがそれにあたる。しかしそれらはHTTPの文法やViewに強く依存し、その機能自体の再利用性はとても低かった。

一方SUGOSの提供するのは透過的な関数なので、関数から別の関数を呼び出すといった再利用がしやすい形にしてある

[FAQ] ROSとの違いは？

	ROS	SUGOS
実態	メッセージングとビルドシステム、その他豊富なライブラリ	Javascriptでリモート関数を定義、実行するための仕組み
対象	ロボットアプリケーション開発	ロボットなどを利用したWebアプリケーション開発
活用場面	目的特化のロボットの開発	複数のデバイスやWebAPIのマッシュアップ、WebUIの提供
動作環境	Ubuntuのみ	OSX, Linux全般 (Node.jsが稼動すれば良い)

ROSはロボット開発全般を対象とした仕組みであるのに対し、SUGOSはWeb化するところにフォーカスを当てている。ROSで開発したアプリケーションをSUGOSから使うことも可。

衝突回避のようなその場での判断が必要になるような処理はSUGOSには向いていない。そうした機能を遠隔からオン・オフするなど、時差を許容できる部分に向いている

ROS単体だとWebアプリケーション化する部分や、外部WebAPIと連動するのに手間がかかるが、SUGOSを使うとそれらの部分の手間が減る

[FAQ]gRPCとの違いは

	SUGOS	gRPC
データののシリアライズ	JSON文字列	Protocol Buffer
呼び出し構造	クライアントが提供する関数を、Hubサーバを経由して別クライアントから呼び出す	サーバが提供した関数をクライアントから呼び出す
関数の実装方法	関数を実装すると、自動的にインターフェースを解析して共有する	インターフェースファイル(.proto)を先に定義し、そこから雛形を自動生成した後、中身を実装する
対応言語	JavaScript	C++ C# GO JAVA PYTHON、等
ブラウザ上での実行	可能	（今のところは）不可能
想定システム	ユーザーインターフェースを備えた遠隔アプリケーション	言語やネットワークをまたいだ分散処理

callerが接続時に送る messages が空のとき、actor側で受け取るデータは undefined にしてほしい

@okunishinishi
これができるようになってほしいが、エラーで落ちる。

  actor.on(JOIN, async ({ caller, messages = {} }) => {
      console.log(messages) // null
      let { token } = messages
      let ok = false
      if (ok) {
        console.log('Add', caller.key)
        eventFilter.add(caller.key)
      }
  })

// Caller side
{
  const shoppingMall = await caller.connect('shoppingMall', {
    // Custom data to pass actor
    data: {
      account: 'hec会員01',
      password: 'hogehoge'
    }
  })

  const fruitShop = shoppingMall.get('fruitShop')

  fruitShop.buyApple(100)

  fruitShop.on('New apple arrived', () => {
    /* ... */
  })

}

// On Hub

// Actor side
{

  let fruitShop = new Module({

    buyApple (amount) {
      /* ... */
      return 1
    }
  })
  let shoppingMall = sugoActor({
    kety: 'shoppingMall',
    modules: {
      fruitShop
    }
  })

  // Namespace to hold callers
  fruitShop.fruteCustomers = {}

  // Called on caller connect
  shoppingMall.on('sugos:caller:conntect', (caller, data) => {
    /* ... */
  })

  // Called on caller connect
  fruitShop.on('sugos:caller:conntect', (caller, data) => {
    let { account, password } = data
    if (!isValud({ account, password })) {
      throw new Error('invalid!')
    }
    // Hold custom data
    fruitShop.fruteCustomers[ caller.id ] = {
      account,
      visitedAt: new Date(9)
    }
  })

  db.on('something changed', () => {
    fruitShop.emit('New apple arrived', { amount }, {
      only: Object.keys(shoppingMall.fruteCustomers) // Fiter emit target callers
    })
  })
}

Apache Thrift を使えるようにする

http://thrift.apache.org/

他言語のクライアントを自動生成するところまでやっちゃえると素敵

Actor Key管理の仕組みを作る

現状はActor側からKeyを自己宣言する仕組みのみである。

  let actor = sugoActor(CLOUD_URL, {
    key: 'my-actor-01'
  })

しかしこれだけだと一意性、なりすまし等の問題が残る

これに加え、属性情報等をもとにCloudにkeyを発行してもらう仕組みをつくる。

  let key = sugoActor.acuireKey(CLOUD_URL, { /* ... */})
  let actor = sugoActor(CLOUD_URL, { key })

Cloud側のプラグインで実現できるような形がよいか

オープンソース化までの作業

本体実装

ライブラリ実装

SUGO Module
- SUGO Module Mavlink
- SUGO Module ArDrone
- SUGO Module PLEN
- SUGO Module RAPIRO
- SUGO Module Pepper
SUGO Scaffold
- SUGO Scaffold
- SUGO Scaffold Python

SUGO Desktop

SUGO Desktop WebCom
SUGO Desktop Screen

SUGO Example

SUGO Example PLEN
SUGO Example RAPIRO
SUGO Example Pepper
SUGO Example ArDone

ドキュメンテーション

広報

コンポーネンントの命名を見直す

Spot/Interface/Terminalと意味がだいぶずれてきた。

明日7/15までいいのが見つからなかったら

Caller
Callee
Module

になるぜ

SUGO-Cloudのサービスサイトを用意する

いちいち自分でSUGO-Cloudを設定しなくてよいように。

Hub に接続できる Actor, Caller の数の上限についての調査結果

1. Socket.IO の場合

参考値として、Socket.IO のみを使うとどのくらい接続できるか調べた。以下の結果はマシンスペックによっても異なると思われる。

Socket.IO 単純接続

クライアントをひたすら接続させると、1 つの Socket.IO サーバーにつき約 20000 〜 30000 個が限界。

サーバーが返事をしなくなる。新規の接続はできなくなるが、メッセージの送受信は問題なくできた。

{ Error: xhr poll error
    at XHR.Transport.onError (/home/fujiharuka/sg/sugos-browser-connect-test/node_modules/engine.io-client/lib/transport.js:62:13)
   ...
    at Timer.listOnTimeout (timers.js:202:5) type: 'TransportError', description: 503 }

Socket.IO ブラウザからの接続

ブラウザからの接続は 260 程度が限界。

2. SUGOS の場合

SUGOS 単純接続

Hub を立ててひたすら Actor をつなげると、約 4000 個接続できる。 Actor, Caller のペアを接続させても最大値はほぼ変化しない。

SUGOS ブラウザからの接続

ブラウザからの接続は 260 程度が限界。

3. 考察

Node.js のプロセスはV8の制限でメモリ1.5GBまでらしいので、Node.jsを使った Hub のボトルネックはメモリではないか。
ブラウザ接続のボトルネックは Socket.IO なので、新規の接続をせずに Caller を増やす方法を考えるべき。

エラーの定義化

Callerからの呼び出しで何か失敗した時、

Actor側での例外
Netowrkの問題

というのを切り分けられるように、エラーの形式をちゃんと決めたい

realglobe-inc / sugos Goto Github PK

sugos's People

Contributors

Stargazers

Watchers