Notatki ze spotkania współpracowników TFF 9.09.2022, Notatki ze spotkania współpracowników TFF 9.09.2022

  • Omówienie propozycji Jeremy’ego, ciąg dalszy
  • Co konkretnie omówić - przejdź przez oba + sprawdź, czy rozumiesz TFF
  • Krótkie podsumowanie dla nowych odbiorców:
    • W tej chwili cała komunikacja inicjowana przez serwer / koordynatora do klientów
    • W wielu scenariuszach klienci nie mogą być adresowani, nie mają przychodzących punktów końcowych
    • Chcesz mieć konfigurację z punktem końcowym po stronie serwera, z którym chcesz się połączyć
    • Pożądany dodatek do ekosystemu, odpowiedni dla wielu scenariuszy zastosowań
  • Problem zidentyfikowany w propozycji Jeremy'ego - koncepcja magazynu zadań, w którym są przesyłane wszystkie odpowiedzi, jest sprzeczna z właściwościami prywatności, które staramy się zachować. Przepływ danych do serwera musi odbywać się za pośrednictwem operatorów federacyjnych i nie powinien odbywać się na poziomie szczegółowości poszczególnych żądań/odpowiedzi wykonawców TFF.
  • (omówienie protokołu wykonawczego TFF)
  • (kilka minut koncepcyjnego wprowadzenia do interfejsu executora w tym nagraniu YouTube )
  • TFF obsługuje wdrażanie w dwóch reżimach:
    • Klienci stanowi.
      • Ogólny interfejs executora TFF jest przeznaczony do obsługi tego trybu.
      • Klienci hostują wykonawców.
      • Uchwyty zwrócone w odpowiedzi na żądania executora przechowują stan po stronie klienta.
      • Przekazywanie tych uchwytów do kolejnych żądań executora obsługuje operacje po stronie klienta i potokowanie.
      • Jest to z pewnością możliwe w przypadku połączeń inicjowanych przez klienta, chociaż obecnie w repozytorium TFF nie ma komponentu zaprojektowanego do tego celu.
      • W przypadku połączeń inicjowanych przez klienta kontrola jest nadal odgórna, sterowana przez wykonawcę po stronie serwera.
      • Podczas gdy mechanizmy organizowania wymiany żądań i odpowiedzi mogą się różnić w zależności od tego, która strona inicjuje komunikację, czy połączenia są długotrwałe itp., na poziomie logicznym żądania nadal są wysyłane przez serwer.
      • Klient może wielokrotnie kontaktować się z serwerem, aby przesyłać odpowiedzi i prosić o kolejne żądania.
      • Klient nadal zachowuje stan lokalnie, ponieważ utrzymuje kontakt z serwerem.
      • Utrata stanu na kliencie lub przekroczenie limitu czasu na serwerze nadal powoduje niepowodzenie całego obliczenia (tak samo jak w przypadku zwykłej konfiguracji executora).
    • Klienci bezstanowi.
      • Nie jest kompatybilny z ogólnym protokołem executora TFF, jak powyżej.
      • Ale może to być obsługiwane przez kompilator MapReduce — istnieje funkcja biblioteki w TFF w module tff.mapreduce.backends do tłumaczenia klas obliczeń TFF na formularz podobny do MapReduce, który może działać w trybie klienta bezstanowego.
  • Kolejne kroki: Propozycja Jeremy'ego może zostać uratowana (ale musi uwzględniać stanowczość po stronie klienta)