Notas da reunião de colaboradores da TFF de 09/09/2022,Notas da reunião de colaboradores da TFF de 09/09/2022

  • Discussão da proposta de Jeremy, continuou
  • O que cobrir especificamente - percorra ambos + verifique o entendimento do TFF
  • Breve recapitulação para o novo público:
    • Neste momento, todas as comunicações iniciadas pelo servidor/coordenador aos clientes
    • Em muitos cenários, os clientes não podem ser endereçados, eles não têm endpoints de entrada
    • Deseja uma configuração com endpoint do lado do servidor para se conectar
    • Adição desejável ao ecossistema, relevante para muitos cenários de aplicação
  • Problema identificado na proposta de Jeremy - o conceito de um armazenamento de tarefas onde todas as respostas são carregadas está em desacordo com as propriedades de privacidade que estamos tentando preservar. O fluxo de dados para o servidor deve ser mediado pelos operadores federados e não deve ocorrer na granularidade das solicitações/respostas individuais do executor do TFF.
  • (discussão do protocolo executor TFF)
  • (alguns minutos de introdução conceitual à interface do executor nesta gravação do YouTube )
  • O TFF suporta a implantação em dois regimes:
    • Clientes estatais.
      • A interface geral do executor TFF foi projetada para suportar este modo.
      • Os clientes hospedam executores.
      • Os identificadores retornados em resposta às solicitações do executor mantêm o estado do lado do cliente.
      • Passar esses identificadores para solicitações de executores subsequentes oferece suporte a operações e pipeline do lado do cliente.
      • Isso certamente é possível com conexões iniciadas pelo cliente, embora não haja nenhum componente atualmente no repositório TFF projetado para isso.
      • Com conexões iniciadas pelo cliente, o controle ainda é de cima para baixo, conduzido pelo executor no lado do servidor.
      • Enquanto os mecanismos para orquestrar a troca de solicitações e respostas podem variar dependendo de qual parte inicia a comunicação, se as conexões são de longa duração, etc., em um nível lógico, as solicitações ainda são emitidas pelo servidor.
      • O cliente pode contatar o servidor repetidamente para alimentar as respostas e solicitar solicitações subsequentes.
      • O cliente ainda mantém o estado localmente, pois continua entrando em contato com o servidor.
      • A perda de estado no cliente ou o tempo limite no servidor ainda resulta em falha de todo o cálculo (o mesmo que na configuração regular do executor).
    • Clientes sem estado.
      • Não compatível com o protocolo geral do executor TFF, conforme acima.
      • Mas, ele pode ser suportado pelo compilador MapReduce - há uma função de biblioteca em TFF no módulo tff.mapreduce.backends para traduzir classes de cálculos TFF em uma forma semelhante a MapReduce que pode operar no regime de cliente sem estado.
  • Próximas etapas: a proposta de Jeremy pode ser recuperada (mas precisa incorporar statefulness no lado do cliente)