여러 업로드 방지

파일을 업로드할 때 BITS는 BITS 클라이언트와 BITS 서버 모두에 대한 업로드 세션을 식별하는 세션 ID를 만듭니다. BITS가 파일을 업로드하는 동안 BITS 클라이언트와 서버 간의 연결이 끊어진 경우 클라이언트는 세션 ID를 사용하여 업로드를 다시 시작합니다.

BITS 클라이언트가 이전과 동일한 서버에 연결하는 경우 서버는 세션 ID를 인식하고 중단 지점에서 업로드가 다시 시작됩니다. 그러나 클라이언트가 다른 서버에 연결하는 경우 새 서버에 세션 컨텍스트 또는 이전에 업로드한 데이터가 없기 때문에 클라이언트는 처음부터 업로드를 시작해야 합니다. BITS 서버가 웹 팜에서 호스트되고 BITS IIS 확장 속성인 BITSHostId가 설정되지 않은 경우 BITS가 다른 서버에 연결할 수 있습니다. BITSHostId 속성은 BITS 클라이언트가 공유 서버 주소 대신 이전 서버의 고유 주소에 연결하도록 강제하여 다시 시작을 방지합니다.

BITS 서버는 업로드 파일을 서버 애플리케이션에 한 번만 보내려고 시도하지만 파일이 두 번 이상 전송될 수 있습니다. 예를 들어 BITS 서버가 서버 애플리케이션에 파일을 보낸 다음 서버 애플리케이션에서 회신을 기다리는 동안 종료되는 경우 이 문제가 발생할 수 있습니다. BITS 클라이언트는 HTTP 계층에서 오류 코드를 수신하고 지연 후 업로드를 다시 시도합니다. 서버가 BITSHostIdFallbackTimeout 시간 제한보다 오랫동안 오프라인 상태로 유지되면 클라이언트는 결국 공유 서버 주소로 요청을 다시 보냅니다. 다른 BITS 서버가 파일을 수신하고 서버 애플리케이션에 다시 전달합니다.

단일 프런트 엔드 서버에서도 비슷한 사례가 발생할 수 있습니다. 예를 들어 클라이언트가 전체 파일을 서버에 업로드하면 최종 블록으로 인해 서버가 파일을 서버 애플리케이션으로 전달합니다. 파일을 처리한 후 클라이언트에 승인을 보내기 전에 BITS 서버 또는 서버 애플리케이션이 종료되면 클라이언트는 오류 코드를 수신하고 나중에 다시 시도합니다. 클라이언트가 다시 시도하면 BITS 서버는 최종 블록이 업로드된 것을 확인하고 파일을 서버 애플리케이션으로 다시 전달합니다. 업로드 파일을 여러 번 받는 것이 서버 애플리케이션에 문제가 되는 경우 데이터에 트랜잭션 식별자를 포함하는 것이 좋습니다.