Notas de la reunión del 9/9/2022 de colaboradores del TFF,Notas de la reunión del 9/9/2022 de colaboradores del TFF

  • Discusión de la propuesta de Jeremy, continuación
  • Qué cubrir específicamente: repasar ambos + verificar contra la comprensión de TFF
  • Breve resumen para la nueva audiencia:
    • En este momento, toda la comunicación iniciada por el servidor/coordinador a los clientes
    • En muchos escenarios, no se puede abordar a los clientes, no tienen puntos finales de ingreso
    • Quiere una configuración con un punto final del lado del servidor para conectarse
    • Adición deseable al ecosistema, relevante para muchos escenarios de aplicación
  • Problema identificado en la propuesta de Jeremy: el concepto de un almacén de tareas donde se cargan todas las respuestas está en desacuerdo con las propiedades de privacidad que estamos tratando de preservar. El flujo de datos al servidor debe ser mediado por los operadores federados, y no debería estar ocurriendo en la granularidad de las solicitudes/respuestas individuales del ejecutor de TFF.
  • (discusión del protocolo ejecutor TFF)
  • (unos minutos de introducción conceptual a la interfaz del ejecutor en esta grabación de YouTube )
  • TFF admite la implementación en dos regímenes:
    • Clientes con estado.
      • La interfaz general del ejecutor TFF está diseñada para admitir este modo.
      • Los clientes alojan ejecutores.
      • Los identificadores devueltos en respuesta a las solicitudes del ejecutor mantienen el estado del lado del cliente.
      • Pasar esos identificadores a las solicitudes posteriores del ejecutor admite las operaciones y la canalización del lado del cliente.
      • Esto es ciertamente posible con conexiones iniciadas por el cliente, aunque actualmente no hay ningún componente en el repositorio TFF diseñado para esto.
      • Con las conexiones iniciadas por el cliente, el control sigue siendo de arriba hacia abajo, impulsado por el ejecutor del lado del servidor.
      • Mientras que los mecanismos para orquestar el intercambio de solicitudes y respuestas pueden variar según la parte que inicia la comunicación, si las conexiones duran mucho tiempo, etc., en un nivel lógico, el servidor sigue emitiendo solicitudes.
      • El cliente puede comunicarse con el servidor repetidamente para enviar respuestas y solicitar solicitudes posteriores.
      • El cliente aún conserva el estado localmente mientras sigue contactando al servidor.
      • La pérdida de estado en el cliente o el tiempo de espera en el servidor aún da como resultado la falla de todo el cálculo (igual que en la configuración normal del ejecutor).
    • Clientes apátridas.
  • Próximos pasos: la propuesta de Jeremy se puede salvar (pero necesita incorporar estado en el lado del cliente)