Path: blob/master/site/pt-br/federated/collaborations/notes/2022-09-08.md
25118 views
Notas do encontro dos colaboradores do TFF em 09/09/2022
Continuação da conversa sobre a proposta de Jeremy
O que queremos abordar especificamente – Avaliar os dois e verificar de acordo com o entendimento do TFF
Breve recapitulação para o novo público:
No momento, toda a comunicação iniciada pelo servidor/coordenador para os clientes
Em diversos cenários, os clientes não podem ser endereçados, eles não têm endpoints de entrada
Queremos uma configuração com um endpoint no lado do servidor ao qual conectar
Inclusão desejável ao ecossistema, relevante em diversos cenários de aplicações
Problema identificado na proposta de Jeremy: o conceito de um repositório de tarefas no qual todas as respostas são carregadas entre em conflito com as propriedades de privacidade que estamos tentando preservar. O fluxo de dados para o servidor precisa ser mediado pelos operadores federados e não deve ocorrer na granularidade de solicitações/respostas de executores individuais do TFF.
(Conversa sobre o protocolo do executor do TFF)
(Alguns minutos de introdução conceitual à interface do executor neste vídeo do YouTube)
O TFF tem suporte à implantação em dois modos:
Clientes stateful.
A interface geral do executor do TFF foi desenvolvida para dar suporte a este modo.
Os clientes hospedam os executores.
Os identificadores retornados em resposta às solicitações dos executores armazenam o estado no lado dos clientes.
O processamento desses identificadores em solicitações subsequentes dos executores tem suporte a operações e criação de pipeline no lado dos clientes.
Isso é plenamente possível com conexões iniciadas pelo cliente, embora não exista um componente no repositório do TFF criado para isso.
Com as conexões iniciadas pelo cliente, o controle ainda é top-down, feito pelo executor no servidor.
Embora os mecanismos para orquestrar a troca de solicitações e respostas possa variar dependendo de qual parte inicia a comunicação, se as conexões estiverem ativas por muito tempo, 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 respostas e fazer solicitações subsequentes.
O cliente ainda mantém o estado localmente enquanto continua contatando o servidor.
A perda de estado no cliente ou o tempo limite no servidor ainda resulta em falha de toda a computação (da mesma forma que na configuração comum do executor).
Clientes stateless.
Não compatíveis com o protocolo geral do executor do TFF, conforme discutido acima.
Mas são compatíveis com o compilador de MapReduce – há uma função de biblioteca no TFF no módulo tff.mapreduce.backends module para traduzir classes de computações do TFF em uma forma tipo MapReduce que pode operar o modo de clientes stateless.
Próximos passos: a proposta de Jeremy pode ser recuperada (mas precisa incorporar o modo stateful no lado dos clientes)