IPC通信

[marihachi]

今はIpcServerChannel、IpcClientChannelを使ってるみたいだけど、より低レベルなAPIでプロトコルを定義して送受信する方法もあるよ
https://qiita.com/oedkty/items/24893e9188e6ec4908cc

[Asteriskx]

展開してくれたのは、知っててあえて書かなかった。
できるかだけの検証をやってみたかったのよね。
まあ、あくまでもサンプルなので。。

[Asteriskx]

コネクション型～～～～～～～～～～～～～～～
♰👼♰

[marihachi]

検討ログ

プラグイン探索時に中央サーバーが必要になると面倒という話に。
中央サーバーはなしで、アプリケーション側と複数のプラグイン側で通信するためには、
一対一のコネクション型の通信では無理ということに。
最終的にローカルでUDPソケットを使うことになった。
コネクションレスのソケットを利用すれば、C#プラグインとC#アプリ間以外(C#プラグイン-Node.jsアプリ間など)でも通信ができる。
ただし、ローカルのやり取りでもパケットがファイアーウォールに引っかかる可能性があるため、
その説明は必要ということに。

[marihachi]

全プラグインを把握しているプロセスがいないので、
IPCでP2Pをするみたいな話になるかもね。
https://ja.wikipedia.org/wiki/Peer_to_Peer
ここのインデックス情報の持ち方という節に似たような話が出てきてる

[marihachi]

スコープを絞ったマルチキャストでIPCを実現する方向で進行中

[marihachi]

この案は廃止

こんなの考えた
アプリケーションがTCPサーバーとなる方式
プラグインはアプリケーションが起動するのを待機する
TCPの代わりにUnixDomainでも良いかも

[marihachi]

HTTPを使った案も考えた

---

アプリケーションがHTTPサーバ、プラグインがHTTPクライアントとして振る舞う。

最初にプラグインはアプリケーションにセッション生成(POST /plugin/session/generate )を送信する。失敗したら再試行。
セッションが生成できたら、プラグインは定期的にPOST /plugin/session/keepを送信しセッションを維持する。
プラグインは配信しているコンテンツに変更があると、アプリケーションにPOST /plugin/content/update を通じて配信する。

アプリケーションは各プラグインセッションの有効期限を管理する。
アプリケーションは各プラグインから配信されたコンテンツを管理する。

HTTP API

POST /plugin/session/generate

プラグインセッションの生成
<パラメータ>
meta: プラグインの基本的情報
<レスポンス>
セッションキー

POST /plugin/session/keep

定期的に送信することでプラグインセッションを維持する
<パラメータ>
key: セッションキー

POST /plugin/content/update

プラグインが提供しているデータの更新
<パラメータ>
key: セッションキー
content: プラグインが提供しているデータ

[marihachi]

アプリケーション・プラグイン間のHTTPの実験中