2022년 9월 9일 TFF 협력자 회의 메모,2022년 9월 9일 TFF 협력자 회의 메모

  • Jeremy의 제안에 대한 토론, 계속
  • 구체적으로 다룰 내용 - 둘 다 살펴보기 + TFF에 대한 이해 여부 확인
  • 신규 고객을 위한 간략한 요약:
    • 현재 서버/코디네이터가 클라이언트에 대해 시작한 모든 통신
    • 많은 시나리오에서 클라이언트는 주소를 지정할 수 없으며 수신 엔드포인트가 없습니다.
    • 연결할 서버 측 끝점이 있는 설정을 원합니다.
    • 많은 애플리케이션 시나리오와 관련된 생태계에 대한 바람직한 추가
  • Jeremy의 제안에서 확인된 문제 - 모든 응답이 업로드되는 작업 저장소의 개념은 우리가 보존하려는 개인 정보 속성과 상충됩니다. 서버로의 데이터 흐름은 연합 운영자에 의해 중재되어야 하며 개별 TFF 실행자 요청/응답의 세분성에서 발생해서는 안 됩니다.
  • (TFF 실행 프로토콜에 대한 논의)
  • ( 이 YouTube 녹음에서 실행자 인터페이스에 대한 몇 분의 개념 소개)
  • TFF는 두 가지 방식으로 배포를 지원합니다.
    • 상태 저장 클라이언트.
      • 일반 TFF 실행기 인터페이스는 이 모드를 지원하도록 설계되었습니다.
      • 클라이언트는 실행자를 호스트합니다.
      • 실행자 요청에 대한 응답으로 반환된 핸들은 클라이언트 측 상태를 유지합니다.
      • 이러한 핸들을 후속 실행기 요청에 전달하면 클라이언트 측 작업 및 파이프라이닝이 지원됩니다.
      • 이것은 클라이언트가 시작한 연결로 확실히 가능하지만 현재 이를 위해 설계된 TFF 리포지토리에는 구성 요소가 없습니다.
      • 클라이언트 시작 연결에서 제어는 여전히 하향식이며 서버 측 실행기에 의해 구동됩니다.
      • 요청 및 응답 교환을 조정하는 메커니즘은 통신을 시작하는 당사자, 연결이 오래 실행되는지 여부 등에 따라 다를 수 있지만 논리적 수준에서 요청은 여전히 ​​서버에서 발행됩니다.
      • 클라이언트는 서버에 반복적으로 접속하여 응답을 제공하고 후속 요청을 요청할 수 있습니다.
      • 클라이언트는 서버에 계속 접속하므로 여전히 로컬로 상태를 유지합니다.
      • 클라이언트의 상태 손실 또는 서버의 시간 초과는 여전히 전체 계산의 실패를 초래합니다(일반 실행기 설정에서와 동일).
    • 무국적 클라이언트.
  • 다음 단계: Jeremy의 제안은 구제될 수 있습니다(그러나 클라이언트 측에서 상태 유지를 통합해야 함).