2022 年 9 月 9 日 TFF 协作者会议笔记

  • 继续讨论 Jeremy 的提案
  • 具体涵盖的内容 - 介绍两者 + 验证对 TFF 的理解
  • 针对新受众的简要回顾：
    • 现在，服务器/协调器向客户端发起的所有通信
    • 在许多场景中，客户端无法被寻址，它们没有入口端点
    • 想要一个带服务器端端点的设置来建立连接
    • 生态系统的理想补充，与许多应用场景相关
  • Jeremy 的提案中发现的问题 - 上传所有响应的任务存储的概念与我们试图保留的隐私属性不一致。传输到服务器的数据流必须由联合算子调解，并且不应在单个 TFF 执行器请求/响应的粒度上发生。
  • （TFF 执行器协议的讨论）
  • （在这个 YouTube 录像中，对执行器接口进行了几分钟的概念性介绍）
  • TFF 支持两种部署方式：
    • 有状态的客户端。
      • 一般的 TFF 执行器接口就是为了支持这种模式而设计的。
      • 客户端托管执行器。
      • 响应执行器请求而返回的句柄保持客户端状态。
      • 将这些句柄传递给支持客户端运算和流水线处理的后续执行器请求。
      • 这当然可以通过客户端启动的连接来实现，尽管目前 TFF 仓库中没有为此设计的组件。
      • 对于客户端启动的连接，控制仍然是自上而下的，由服务器端的执行器驱动。
      • 尽管编排请求和响应交换的机制可能会根据启动通信的一方、连接是否长时间运行等而有所不同，但在逻辑级别上，请求仍由服务器发出。
      • 客户端可以反复联系服务器以提供响应并要求后续请求。
      • 客户端在与服务器保持联系的同时仍会在本地保留状态。
      • 客户端状态丢失或服务器超时仍会导致整个计算失败（与常规执行器设置相同）。
    • 无状态客户端。
      • 如上面所述，与通用 TFF 执行器协议不兼容。
      • 但是，它可以由 MapReduce 编译器提供支持 – TFF 的 tff.mapreduce.backends 模块中有一个库函数，用于将 TFF 计算的类转化为可以在无状态客户端方式下运行的类似 MapReduce 的形式。
  • 接下来的步骤：Jeremy 的提案是可以挽救的（但需要在客户端加入有状态性）