다음을 통해 공유

연결 끊기 처리

  • 아티클

RPC 호출이 완료되면 연결이 닫혀 있지 않습니다. 무료로 표시됩니다. 따라서 연결이 풀에 있는 동안 서버가 다운되거나 호출 중 또는 그 사이에 네트워크 연결이 끊어질 수 있습니다. 정책의 문제로 RPC 런타임은 다음 두 조건이 충족되는 경우에만 해당 호출을 다시 시도합니다.

  • 서버에서 호출을 실행할 수 없거나 호출이 idempotent일 수 있습니다.
  • 클라이언트는 성능 효율적인 방식으로 재시도를 구현할 수 있습니다.

다음 단락은 두 조건을 확장하고 명확히 설명합니다.

idempotent 호출은 바람직하지 않은 부작용 없이 서버에서 두 번 이상 실행할 수 있는 호출입니다. 예를 들어 은행에서 지정된 계좌에 대한 잔액을 쿼리하는 RPC 호출을 갖는 것은 idempotent입니다. 연결 손실로 인해 이 호출이 두 번 실행되면 아무런 피해도 발생하지 않습니다. 멱등 호출의 또 다른 예는 데이터베이스에서 고객의 주소를 변경하는 것입니다. 두 번째 실행은 이미 현재 주소를 동일한 주소로 바꾸기 때문에 두 번 실행하는 것은 괜찮습니다. "계정 xyz에서 50달러를 빼기"와 같은 작업은 idempotent가 아닙니다. 네트워크 연결이 끊어지면 이러한 호출이 여러 차례 실행되지 않아야 합니다.

안전을 위해 RPC 런타임은 모든 호출을 비 멱등성으로 처리합니다. [idempotent] 특성은 ncacn_ip_tcp 지원되지 않으며 무시됩니다. 따라서 이전 목록의 첫 번째 조건이 호출을 실행할 수 없는 서버로 축소됩니다.

대부분의 경우 RPC 런타임은 서버에서 호출이 아직 실행되지 않았다는 것을 결정적으로 확인할 수 없습니다. 이러한 경우 클라이언트는 호출 실행을 다시 시도하지 않습니다.

다음 예제에서는 RPC 런타임이 호출을 수행하거나 다시 시도하지 않는 경우를 보여 줍니다.

  • 서버를 다시 부팅합니다.

    다시 부팅 후 이전 호출이 이루어지지 않은 인터페이스에서 간단한 보안 없음 RPC 호출이 이루어집니다. 이 인터페이스에서 호출이 수행되지 않으므로 RPC 런타임은 먼저 인터페이스 사용을 협상하려고 시도합니다. 풀에서 연결을 사용하여 패킷을 보냅니다. 서버가 다시 부팅되고 연결이 더 이상 유효하지 않으므로 오류가 반환됩니다. 클라이언트 쪽 RPC 런타임이 아직 실제 호출에 대한 데이터 전송을 시작하지 않았기 때문에 클라이언트는 서버가 해당 데이터에 대해 실행되지 않았을 수 있다고 결정합니다. 따라서 연결을 닫고 풀에서 다른 연결을 찾습니다. 연결을 찾을 수 없는 경우 새 연결을 열고 인터페이스 사용을 다시 협상하려고 시도합니다. 이 작업이 성공하면 호출이 수행됩니다(즉, 호출이 시작되기 전에 오류가 감지되었기 때문에 다시 시도).

  • 이미 협상된 보안 컨텍스트와의 연결에서 개인 정보 수준 보안(암호화)을 사용하는 RPC 호출이 이루어집니다.

    효율적인 성능을 보장하기 위해 RPC 런타임은 마샬링된 패킷을 인라인으로 암호화합니다(명확한 텍스트 데이터를 통해). 데이터 전송 시도가 실패하면 명확한 텍스트 데이터를 암호화된 데이터로 덮어쓰고 새 보안 컨텍스트로 데이터를 다시 암호화할 수 없으므로 RPC 런타임에서 호출을 다시 시도할 수 없습니다. 따라서 다시 시도하지 않습니다.

  • 첫 번째 조각이 아닌 조각을 보내는 데 실패합니다.

    RPC 런타임이 완료되면 첫 번째 조각의 내용을 삭제하도록 선택할 수 있으며 첫 번째 조각 전송을 다시 시도할 방법이 없으므로 다시 시도하지 않습니다.

  • RPC 요청이 전송됩니다.

    서버가 연결을 중단합니다. RPC는 서버가 호출을 수신하고 실행을 시작했는지 여부를 식별할 수 없으므로 다시 시도하지 않습니다.

서버에서 동적 엔드포인트를 사용하는 경우 RPC는 재시도 중에 엔드포인트를 다시 resolve 않습니다. 즉, 서버가 다운되어 다시 제공되는 경우 다른 엔드포인트에 상주할 수 있으며 호출을 다시 시도하면 RPC가 엔드포인트를 투명하게 다시 resolve 않습니다. 엔드포인트를 강제로 다시 확인하려면 RPC 클라이언트가 호출을 다시 시도하기 전에 RpcBindingReset 을 호출해야 합니다.

이러한 많은 경우 RPC 클라이언트가 호출이 멱등성인지 여부를 확인할 수 있거나 RPC가 삭제하는 데이터를 유지하는 경우 RPC를 기반으로 재시도 메커니즘을 빌드하도록 선택할 수 있습니다.

참고

서버가 클러스터이고 클러스터의 다른 노드가 다른 버전의 서버 소프트웨어를 실행하는 경우 RPC 재시도는 장애 조치(failover)의 경우 클러스터의 다른 노드 및 잠재적으로 다른 버전의 서버에서 호출을 수행할 수 있습니다. 이러한 배포 시나리오에서 클라이언트가 특정 버전의 서버 소프트웨어를 사용하여 지정된 호출을 실행하지 않는지 확인합니다. 이 경우 클라이언트는 RPC를 기반으로 이러한 조건을 감지하고 처리하는 메커니즘을 빌드해야 합니다.