2022 年 9 月 9 日の TFF 協力者会議のメモ,2022 年 9 月 9 日の TFF 協力者会議のメモ

  • ジェレミーの提案についての議論、続き
  • 具体的に何をカバーするか - 両方を説明し、TFF の理解を確認します
  • 新しい聴衆のための簡単な要約:
    • 現時点では、サーバー/コーディネーターからクライアントへのすべての通信が開始されます
    • 多くのシナリオでは、クライアントに対処できず、イングレス エンドポイントがありません。
    • 接続するサーバー側のエンドポイントを設定したい
    • 多くのアプリケーション シナリオに関連する、エコシステムへの望ましい追加
  • Jeremy の提案で特定された問題 - すべての応答がアップロードされるタスク ストアの概念は、私たちが守ろうとしているプラ​​イバシー プロパティと矛盾しています。サーバーへのデータ フローは、フェデレーション オペレーターによって仲介される必要があり、個々の TFF エグゼキューターの要求/応答の粒度で発生するべきではありません。
  • (TFF executor プロトコルの議論)
  • (この YouTube レコーディングのエグゼキューター インターフェイスの概念的な紹介の数分)
  • TFF は、次の 2 つの体制での展開をサポートしています。
    • ステートフル クライアント。
      • 一般的な TFF エグゼキュータ インターフェイスは、このモードをサポートするように設計されています。
      • クライアントはエグゼキュータをホストします。
      • Executor 要求に応答して返されるハンドルは、クライアント側の状態を保持します。
      • これらのハンドルを後続のエグゼキュータ リクエストに渡すことで、クライアント側の操作とパイプライン処理がサポートされます。
      • これは、クライアントが開始した接続で確かに可能ですが、現在、このために設計された TFF リポジトリにはコンポーネントがありません。
      • クライアントが開始する接続では、制御は依然としてトップダウンであり、サーバー側のエグゼキューターによって駆動されます。
      • 要求と応答の交換を調整するメカニズムは、通信を開始する当事者、接続が長時間実行されているかどうかなどによって異なりますが、論理レベルでは、要求は依然としてサーバーによって発行されます。
      • クライアントはサーバーに繰り返し接続して、応答をフィードし、後続の要求を求めることができます。
      • クライアントは、サーバーとの通信を継続するため、ローカルで状態を維持します。
      • クライアントで状態が失われたり、サーバーでタイムアウトが発生したりしても、計算全体が失敗します (通常のエグゼキューターのセットアップと同じです)。
    • ステートレス クライアント。
      • 上記のように、一般的な TFF executor プロトコルとは互換性がありません。
      • ただし、これは MapReduce コンパイラでサポートできます。tff.mapreduce.backends モジュールの TFF にはライブラリ関数があり、TFF 計算のクラスを、ステートレス クライアント体制で動作できる MapReduce のような形式に変換します。
  • 次のステップ: Jeremy の提案は回収できます (ただし、クライアント側にステートフルネスを組み込む必要があります)。