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