Notes de la réunion du 9/9/2022 des collaborateurs de TFF,Notes de la réunion du 9/9/2022 des collaborateurs de TFF

  • Discussion de la proposition de Jeremy, suite
  • Ce qu'il faut couvrir spécifiquement - parcourir les deux + vérifier par rapport à la compréhension de la TFF
  • Bref récapitulatif pour le nouveau public :
    • À l'heure actuelle, toutes les communications initiées par le serveur/coordinateur vers les clients
    • Dans de nombreux scénarios, les clients ne peuvent pas être adressés, ils n'ont pas de points de terminaison d'entrée
    • Vous souhaitez une configuration avec un point de terminaison côté serveur auquel vous connecter
    • Ajout souhaitable à l'écosystème, pertinent pour de nombreux scénarios d'application
  • Problème identifié dans la proposition de Jeremy - le concept d'un magasin de tâches où toutes les réponses sont téléchargées est en contradiction avec les propriétés de confidentialité que nous essayons de préserver. Le flux de données vers le serveur doit être médiatisé par les opérateurs fédérés et ne doit pas se produire à la granularité des demandes/réponses individuelles de l'exécuteur TFF.
  • (discussion du protocole de l'exécuteur TFF)
  • (quelques minutes d'introduction conceptuelle à l'interface de l'exécuteur dans cet enregistrement YouTube )
  • La TFF prend en charge le déploiement dans deux régimes :
    • Clients avec état.
      • L'interface générale de l'exécuteur TFF est conçue pour prendre en charge ce mode.
      • Les clients hébergent des exécuteurs.
      • Les descripteurs renvoyés en réponse aux requêtes de l'exécuteur conservent l'état côté client.
      • La transmission de ces descripteurs aux demandes d'exécuteur ultérieures prend en charge les opérations côté client et le pipelining.
      • Cela est certainement possible avec les connexions initiées par le client, bien qu'il n'y ait actuellement aucun composant dans le référentiel TFF conçu pour cela.
      • Avec les connexions initiées par le client, le contrôle est toujours descendant, piloté par l'exécuteur côté serveur.
      • Alors que les mécanismes pour orchestrer l'échange de requêtes et de réponses peuvent varier selon la partie qui initie la communication, si les connexions durent longtemps, etc., à un niveau logique, les requêtes sont toujours émises par le serveur.
      • Le client peut contacter le serveur à plusieurs reprises pour fournir des réponses et demander des demandes ultérieures.
      • Le client conserve toujours l'état localement car il continue de contacter le serveur.
      • La perte d'état sur le client ou le délai d'attente sur le serveur entraîne toujours l'échec de l'ensemble du calcul (comme dans la configuration normale de l'exécuteur).
    • Clients apatrides.
      • Non compatible avec le protocole général de l'exécuteur TFF, comme indiqué ci-dessus.
      • Mais, il peut être pris en charge par le compilateur MapReduce - il existe une fonction de bibliothèque dans TFF dans le module tff.mapreduce.backends pour traduire les classes de calculs TFF en une forme de type MapReduce qui peut fonctionner dans le régime client sans état.
  • Prochaines étapes : la proposition de Jeremy peut être récupérée (mais doit intégrer l'état du côté client)