Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 200616 AGL_Input_Manager.pptx


議事録メモ

...

以下、PPT資料説明に対する協議内容

  • Containerは常に動作している前提で良いか?
    • アプリContainerが落ちることを前提とすべき。Restartは必要。
    • Server/

...

    • Cilentモデルで、Restartできるようにしておいた方が良い。
  • 大前提として、コンテナ間での通信は作らない方が良い。

      ...

        • Container間の通信が発生するDasiyChainは適さない。
        • Server/

      ...

        • Cilentモデルで、ClientはMultiClient方式にした方が良い。
        • Host側InputManagerをServerとし、アプリContainerはMultiClientとする。
      • この場合の課題はレイテンシーとなる。
          • 構造は複雑となるが、HostContainerInputManagerをネストさせることでレイテンシーを小さくする。
          • Host側のInputManagerClusterContainer内部のInputManager間で、イベント消費する・しない、を判断する。

          ...

          • アプリContainerが死んだときに、どのようにしてHost側のInputManagerに知らせるか?
            • 例えば、ServerClientでセッションが切れたときに、Host側はClientInputManagerが死んだと判断する。
          • アプリContainerが死んでいるときor起動中の時に、Host側のKeyイベントはどうする? 捨てる? キューイングする?
            • Keyイベントは捨てる、で良い。

          ...

          • ADASTripComputerの表示切替など。
          • +/-キーなどは、Clusterは要らない。
          • そもそもで、ClusterIVIで共有するイベントはなさそう。

          ...

          • ClusterIVIKeyイベントの割り当てに関しては静的に決定できるため、動的な変更は考えないこととする。
          • Hostとしては、静的なConfigurationで済ませる。 動的な変更は考えない。
          • HostClusterInputManagerSimpleな形とする。
          • IVIInputManagerは、動的に通知先が変わる・変更する可能性が出てくるので、Hostとは明確に分離する。

          ...

          • Container間通信としては、UNIXドメインソケットが一般的。
          • それ以外の手段としてはVX-CANがあるが、一般的ではない。

          ...

            • 構造は複雑となるが、HostとContainerでInputManagerをネストさせることでレイテンシーを小さくする。
            • Host側のInputManagerとClusterContainer内部のInputManager間で、イベント消費する・しない、を判断する
          • Container内部に配置するInputManagerのLifeCycleが問題になる。
            • アプリContainerが死んだときに、どのようにしてHost側のInputManagerに知らせるか?
              • 例えば、ServerとClientでセッションが切れたときに、Host側はClientのInputManagerが死んだと判断する。
                アプリContainerが死んでいるときor起動中の時に、Host側のKeyイベントはどうする? 捨てる? キューイングする?
                • Keyイベントは捨てる、で良い。
            • Clusterがダイレクトで受けなきゃいけないKeyイベントは何か?
              • ADASやTripComputerの表示切替など。
              • +/-キーなどは、Clusterは要らない。
              • そもそもで、ClusterとIVIで共有するイベントはなさそう。
            • Keyイベントの動的な割り当て・変更は必要か?
              • ClusterとIVIのKeyイベントの割り当てに関しては静的に決定できるため、動的な変更は考えないこととする。
              • Hostとしては、静的なConfigurationで済ませる。 動的な変更は考えない。
              • HostとClusterのInputManagerはSimpleな形とする。
              • IVIのInputManagerは、動的に通知先が変わる・変更する可能性が出てくるので、Hostとは明確に分離する。
            • 実装モデルはどうするか?
              • 通信手段
                • Container間通信としては、UNIXドメインソケットが一般的。
                • それ以外の手段としてはVX-CANがあるが、一般的ではない。
              • API
                • 必要なAPIは、Register、Unregister、Notify、Response、の4つか。
                • Unregisterは必須ではない。実際に使用するかどうかはわからないが、動的に登録解除する可能性もゼロではないため準備する。
                • Responseは、アプリContainer側でイベントが消費したことをResponseするために使用。
              • データフォーマット
                • 規定する必要あり。(次回宿題)
          • 今後

              ...

                • 本日協議内容に基づき、InputManager検討資料の更新 (山岸さん)
                • アーキテクチャOverviewも本日の協議結果に基づき更新可能なので、反映する (丸山)

              次回

              XX/XXの週

              座長:XXX