Notas de la reunión de colaboradores de TFF del 09/09/2022

• Análisis de la propuesta de Jeremy (continuación).

  • TFF Tech Note: Client initiated connections (Nota técnica sobre TFF: conexiones iniciadas por el cliente) (público).

  • TFF Tech Note: Task Assignment (Nota técnica sobre TFF: asignación de tareas) (público).

  • Implementación de prototipos

• Qué se abarcará específicamente: repasaremos ambas opciones + haremos la verificación con lo que se entiende de TFF

• Breve repaso para la audiencia nueva:

  • En este momento, a todas las comunicaciones las inicia el servidor o coordinador hacia los clientes.

  • En muchos escenarios, no se puede trabajar con los clientes, porque no tienen extremos (endpoints) con ingress.

  • Queremos contar con una configuración (con endpoints del lado del servidor) a la cual conectarnos.

  • Es una incorporación deseable para el ecosistema, que sería relevante para muchos escenarios de aplicación.

• Problema identificado en la propuesta de Jeremy: el concepto de una tienda de tareas en la que se carguen todas las respuestas no concuerda del todo con las propiedades de privacidad que intentamos preservar. El flujo de datos al servidor debe estar mediado por los operadores federados y no debería producirse al nivel granular individual de respuestas o solicitudes del ejecutor de TFF.

• (Conversación sobre el protocolo de ejecutores de TFF)

• (Unos minutos de introducción conceptual sobre la interfaz ejecutora que se puede ver en esta grabación de YouTube)

• TFF admite el desarrollo en dos regímenes:

  • El de clientes con estado.

    • La interfaz del ejecutor de TFF general está diseñada para admitir este modo.

    • Los clientes alojan a los ejecutores.

    • Los handles devueltos en respuesta a las solicitudes del ejecutor tienen el estado del lado del cliente.

    • El pasaje de esos handles a las solicitudes de los ejecutores siguientes admite la canalización y las operaciones del lado del cliente.

    • Desde luego, esto es posible con conexiones iniciadas por clientes, aunque no hay ningún componente actualmente en el repositorio de TFF diseñado para tal fin.

    • Con las conexiones iniciadas por clientes, el control todavía se hace de arriba abajo, impulsado por el ejecutor del lado del servidor.

    • Si bien es cierto que los mecanismos para orquestar el intercambio de solicitudes y respuestas puede variar dependiendo de cuáles sean las partes que se comunican, de si las conexiones funcionan durante mucho tiempo, o por otros motivos; a un nivel lógico, las solicitudes aún son emitidas por el servidor.

    • El cliente puede contactar al servidor repetidas veces para alimentarlo con respuestas y pedir las siguientes solicitudes.

    • El cliente aún retiene el estado localmente ya que sigue contactando al servidor.

    • La pérdida del estado en el cliente o el tiempo límite en el servidor todavía da como resultado un fallo del cálculo entero (igual que con la configuración del ejecutor regular).

  • El de clientes sin estado.

    • No es compatible con el protocolo del ejecutor de TFF general, según lo anterior.

    • Pero puede ser compatible con el compilador MapReduce. Hay una función de biblioteca en TFF en el módulo tff.mapreduce.backends para traducir clases de cálculos de TFF en una forma similar a MapReduce que puede funcionar en un régimen de cliente sin estado.

• Próximos pasos: la propuesta de Jeremy se puede rescatar (pero hay que incorporar la falta de estado del lado del cliente).