아웃바운드 속도

네트워크가 제공할 수 있는 최대한 빠른 속도로 아웃바운드 데이터를 처리할 수 있는 충분한 리소스(예: 화면)가 애플리케이션에 있는 경우 또는 상위 수준 프로토콜(예: 즉시 요청 모드)이 데이터 흐름을 제한하는 경우 애플리케이션은 속도에 관여하지 않아도 되며 로컬 노드에서 아웃바운도 속도를 투명하게 처리할 수 있습니다.

그러나 특정 유형의 애플리케이션은 아웃바운드 속도에 관여해야 할 수 있습니다. 애플리케이션에 제한된 리소스(예: 프린터)가 있는 경우 애플리케이션은 Open(PLU) OK Response의 CICB(연결 정보 제어 블록)에서 애플리케이션 속도 옵션을 지정해야 합니다. 자세한 내용은 PLU 연결 열기를 참조하세요. 또한 애플리케이션은 처음에 Open(PLU) OK Response에서 이러한 리소스의 상태에 대한 정보를 로컬 노드에 제공하고 정기적으로 Status-Resource 메시지를 사용하여 제공해야 합니다.

애플리케이션이 Open(PLU) OK Response에서 초기 크레딧 필드를 계산하는 데 도움을 주기 위해 로컬 노드는 Open(PLU) Request에서 속도 창 크기와 기본 및 보조 최대 요청/응답 단위(RU) 크기를 제공합니다. 초기 크레딧은 적어도 기본 및 보조 속도 창 크기만큼 커야 합니다. 그러지 않으면 BIND가 거부되고 Open(PLU) Error Confirm 메시지가 애플리케이션에 전송됩니다. 로컬 노드는 중지-시작 상황을 방지하기 위해 속도 창보다 1이 더 큰 추천 초기 크레딧 값을 채웁니다.

애플리케이션에서 모든 초기 크레딧의 속도와 관련되어야 한다고 지정하는 경우 로컬 노드도 BIND를 거부하지만 BIND는 아웃바운드 속도가 없는 것으로 지정합니다.

FMD(함수 관리 데이터) 요청만 크레딧 체계의 일부이므로 애플리케이션은 초기 크레딧 개수로 지정된 RU 수뿐만 아니라 RU당 하나의 Status-Control 요청에 대해 해당 버퍼 내에서 공간을 유지 관리해야 합니다. Status-Control 메시지는 36바이트를 사용합니다.

애플리케이션이 로컬 노드에 전달하는 각 크레딧 단위를 통해 로컬 노드는 단일 RU(또는 청크가 사용되는 경우 단일 청크)를 애플리케이션에 제공할 수 있습니다. 애플리케이션이 세그먼트를 받는 경우에는 여러 DATAFMI 메시지에 해당할 수 있습니다. 애플리케이션은 BBIU(시작 기본 정보 단위) 및 EBIU(끝 기본 정보 단위) 플래그를 사용하여 아웃바운드 흐름 제어를 위해 RU를 계산할 수 있습니다.

애플리케이션은 Status-Resource 메시지에서 로컬 노드에 보고해야 하는 크레딧 사용 횟수를 유지 관리해야 합니다. 애플리케이션은 다음 작업을 수행해야 합니다.

• EBIU가 설정된 DATAFMI 메시지(FMD 요청에 해당)를 받을 때가 아니라 처리할 때 크레딧 사용 횟수를 1씩 늘립니다.

• 로컬 노드에서 Status-Control 메시지 및 다른 모든 메시지를 처리할 때 크레딧 사용 횟수를 늘리지 않습니다.

• Status-Resource 메시지에 대한 현재 크레딧 사용 횟수를 정기적으로 보고합니다.

• 크레딧 사용 횟수가 0이 아닌 경우 버퍼가 비게 되면 마지막으로 처리된 메시지와 관계없이 크레딧 사용 횟수를 보고합니다.

• 크레딧 사용 횟수가 로컬 노드에 보고되면 0으로 다시 설정합니다.

  애플리케이션이 Status-Resource 메시지를 제공하는 빈도는 설계되지 않습니다. 그러나 로컬 노드는 크레딧을 받은 만큼의 Data 메시지만 애플리케이션에 보냅니다. 애플리케이션의 크레딧 사용 횟수가 초기 크레딧 값에 도달하면 로컬 노드가 더 이상 데이터를 보내지 않습니다. 로컬 노드는 애플리케이션에 Data 메시지를 보낼 수 없고 호스트는 계속 요청을 보내고 있으면 로컬 노드가 성능 저하로 인해 필요할 때 호스트에 속도 응답을 보내지 못할 수 있으므로 애플리케이션은 이 문제가 발생하기 전에 Status-Resource 메시지를 보내려고 시도해야 합니다.

  1 또는 2처럼 속도 창이 작으면 애플리케이션은 각 DATAFMI 메시지를 처리한 후 Status-Resource를 보내 로컬 노드가 적합한 속도 응답을 보낼 수 있도록 해야 합니다.

  다음 그림에서는 애플리케이션이 관련되지 않은 경우(APPLPAC = 0x00) 아웃바운드 속도를 처리하는 로컬 노드를 보여 줍니다. 속도 창은 2로 간주됩니다.

  
  아웃바운드 속도를 처리하는 로컬 노드

  다음 그림에서는 아웃바운드 속도 창이 2로 간주되고 로컬 노드에서 애플리케이션까지의 초기 크레딧이 4로 간주될 때 아웃바운드 속도를 처리하는 로컬 노드 및 애플리케이션을 보여 줍니다. 로컬 노드는 호스트로 IPR(격리된 속도 응답)을 전송하여 애플리케이션이 남은 현재 창과 다음 창에 충분한 크레딧을 보유하게 되는 즉시 데이터로 채워진 다른 창을 가져올 수 있습니다.

  
  아웃바운드 속도를 처리하는 로컬 노드 및 애플리케이션

참고 항목

PLU 연결 열기
PLU 세션
아웃바운드 체이닝
인바운드 체이닝
세그먼트 배달
Brackets
방향
속도 및 청크
데이터 확인 및 거부]
종료 및 정지
복구
애플리케이션에서 시작한 종료
LUSTATS]
응답 시간 모니터 데이터