Appunti dell'incontro dei collaboratori del TFF del 9/9/2022,Appunti dell'incontro dei collaboratori del TFF del 9/9/2022

  • La discussione sulla proposta di Jeremy è proseguita
  • Cosa trattare in particolare: esamina entrambi + verifica rispetto alla comprensione di TFF
  • Breve riassunto per il nuovo pubblico:
    • In questo momento, tutte le comunicazioni avviate dal server/coordinatore ai client
    • In molti scenari, i client non possono essere indirizzati, non hanno endpoint di ingresso
    • Vuoi una configurazione con endpoint lato server a cui connetterti
    • Aggiunta desiderabile all'ecosistema, rilevante per molti scenari applicativi
  • Problema identificato nella proposta di Jeremy: il concetto di task store in cui vengono caricate tutte le risposte è in contrasto con le proprietà della privacy che stiamo cercando di preservare. Il flusso di dati al server deve essere mediato dagli operatori federati e non dovrebbe avvenire con la granularità delle singole richieste/risposte dell'esecutore TFF.
  • (discussione del protocollo esecutore TFF)
  • (alcuni minuti di introduzione concettuale all'interfaccia dell'esecutore in questa registrazione di YouTube )
  • TFF supporta la distribuzione in due regimi:
    • Clienti con stato.
      • L'interfaccia dell'esecutore TFF generale è progettata per supportare questa modalità.
      • I client ospitano gli esecutori.
      • Gli handle restituiti in risposta alle richieste dell'esecutore mantengono lo stato lato client.
      • Il passaggio di tali handle alle successive richieste dell'esecutore supporta le operazioni e la pipeline lato client.
      • Ciò è certamente possibile con le connessioni avviate dal client, anche se attualmente non vi è alcun componente nel repository TFF progettato per questo.
      • Con le connessioni avviate dal client, il controllo è ancora dall'alto, guidato dall'esecutore sul lato server.
      • Mentre i meccanismi per orchestrare lo scambio di richieste e risposte possono variare a seconda della parte che avvia la comunicazione, se le connessioni sono di lunga durata, ecc., a livello logico le richieste vengono comunque emesse dal server.
      • Il cliente può contattare ripetutamente il server per fornire risposte e chiedere richieste successive.
      • Il client conserva ancora lo stato in locale poiché continua a contattare il server.
      • La perdita di stato sul client o il timeout sul server comporta ancora un errore dell'intero calcolo (come nella normale configurazione dell'esecutore).
    • Clienti apolidi.
      • Non compatibile con il protocollo generale dell'esecutore TFF, come sopra.
      • Ma può essere supportato dal compilatore MapReduce: c'è una funzione di libreria in TFF nel modulo tff.mapreduce.backends per tradurre classi di calcoli TFF in una forma simile a MapReduce che può funzionare nel regime client senza stato.
  • Passi successivi: la proposta di Jeremy può essere salvata (ma deve incorporare la statualità sul lato cliente)