Path: blob/master/site/ja/federated/collaborations/notes/2022-09-08.md
25118 views
2022/9/9 の TFF コラボレーターミーティング議事録
（続き）Jeremy の提案に関するディスカッション
具体的に説明する内容 - ウォークスルー + TFF の理解に対する検証
新しいオーディエンス向けの簡単なまとめ
現時点では、すべての通信はサーバー/コーディネーターがクライアントに向けて開始している
多くのシナリオでは、クライアントを言及できず、入力エンドポイントがない
接続先のサーバー側エンドポイントでセットアップしたい
エコシステムへの追加が望まれており、多くのアプリケーションシナリオに関連性がある
Jeremy の提案に見つかった問題 - すべてのレスポンスがアップロードされるタスクストアの概念に、保持しようとしているプライバシー特性との矛盾がある。サーバーへのデータフローは、連合演算子を中継する必要があり、個別の TFF Executor リクエスト/レスポンスのレベルで生じるべきではない。
（TFF Executor プロトコルに関するディスカッション）
（数分程度で Executor インターフェースの入門概念を こちらの YouTube 録画で紹介）
TFF は、以下の 2 つの体制でデプロイをサポート:
ステートフルクライアント
一般的な TFF Executor インターフェースはこのモードをサポートするように設計されている。
クライアントが Executor をホスト。
Executor リクエストに対して返されるハンドルにクライアント側の状態が保持される。
それらのハンドルを後続の Executor リクエストに渡すと、クライアント側の演算とパイプラインがサポートされる。
これはクライアントが開始する接続で確実に可能。ただし、現在、このために設計された TFF リポジトリにはコンポーネントがない。
クライアントが開始した接続の場合、制御はサーバー側の Executor が行うトップダウン方式が維持される。
一方で、リクエストとレスポンスの交換をオーケストレーションする仕組みは、どちらが通信を開始したか、接続が長期間実行しているかなどによって異なる。論理レベルでは、リクエストはサーバーから発行されるままとなる。
クライアントはサーバーに繰り返し問い合わせ、後続のリクエストを求めることができる。
クライアントは、サーバーとの通信を継続すしながらローカルで状態を維持する。
クライアントで状態が失われたり、サーバーでタイムアウトが発生したりしても、計算全体が失敗となる（通常の Executor のセットアップと同じ）。
ステートレスクライアント
上記のように、一般的な TFF Executor プロトコルとの互換性がない。
ただし、これは MapReduce コンパイラでサポート可能。tff.mapreduce.backends モジュールの TFF にはライブラリ関数があり、TFF コンピュテーションのクラスをステートレスクライアント体制で動作できる MapReduce のような形式に変換する。
次のステップ: Jeremy の提案は回収可能（ただし、クライアント側にステートフルネスを組み込む必要がある）。