WebSphere MQ Telemetry Transport는 QoS(Quality of Service)에 정의된 레벨에 따라 메시지를 전달합니다. 아래에 레벨이 설명되어 있습니다.
아래 표에는 QoS 레벨 0 프로토콜 플로우가 표시되어 있습니다.
클라이언트 | 메시지 및 방향 | 브로커 |
---|---|---|
QoS = 0 | PUBLISH |
조치: subscriber로 메시지를 Publish하십시오. |
QoS 레벨이 1인 메시지의 메시지 헤더에는 메시지 ID가 있습니다.
아래 표에는 QoS 레벨 1 프로토콜 플로우가 표시되어 있습니다.
클라이언트 | 메시지 및 방향 | 브로커 |
---|---|---|
QoS = 1 |
PUBLISH |
조치:
|
조치: 메시지 제거 | PUBACK |
클라이언트가 PUBACK 메시지(응용프로그램에 정의된 시간 내에 또는 실패가 감지되어 통신 세션이 다시 시작된 경우에)를 수신하지 못하면, 클라이언트는 DUP 플래그 세트를 사용하여 PUBLISH 메시지를 다시 송신합니다.
브로커가 클라이언트로부터 중복 메시지를 수신하면, 브로커는 메시지를 subscriber에게 다시 publish하고 다른 PUBACK 메시지를 송신합니다.
QoS 레벨이 2인 메시지의 메시지 헤더에는 메시지 ID가 있습니다.
아래 표에는 QoS 레벨 2 프로토콜 플로우가 표시되어 있습니다.
클라이언트 | 메시지 및 방향 | 브로커 |
---|---|---|
QoS = 2 |
PUBLISH |
조치: 데이터베이스에서 메시지 저장 |
PUBREC |
메시지 ID = x | |
메시지 ID = x | PUBREL |
조치:
|
조치: 메시지 제거 | PUBCOMP |
메시지 ID = x |
실패가 감지되었거나 정의된 시간이 지나면, DUP 비트 세트를 사용하여 프로토콜 플로우의 각 부분을 재시도합니다. 추가 프로토콜 플로우는 subscriber에 메시지를 한 번만 전달합니다.
QoS1 및 QoS2는 메시지를 전달해야 함을 표시하므로 브로커는 데이터베이스에 메시지를 저장합니다. 브로커가 이 데이터에 액세스하는 데 문제가 있는 경우 메시지가 손실될 수도 있습니다. 자세한 정보와 이 문제점을 줄이기 위해 취할 수 있는 조치는 Telemetry 응용프로그램 설계를 참조하십시오.
모든 네트워크에서 디바이스 또는 통신 링크가 실패할 가능성이 있습니다. 이러한 상태가 발생하면 링크의 한 쪽 끝은 다른 쪽 끝에서 발생하는 상황을 알 수 없습니다. 이를 인다우트 윈도우라고 합니다. 이 시나리오에서 메시지 전달에 관련된 디바이스 및 네트워크의 신뢰성에 대한 가정을 작성해야 합니다.
WebSphere MQ Telemetry Transport는 클라이언트 및 브로커는 일반적으로 신뢰성이 있으며 통신 채널은 신뢰할 수 없는 통신 채널이라고 가정합니다. 클라이언트 디바이스가 실패한 경우 일반적으로 일시적인 실패가 아니라 심각한 실패입니다. 디바이스로부터 데이터를 복구할 가능성은 낮습니다. 일부 디바이스는 비휘발성 저장영역(예: 플래시 ROM)을 갖고 있습니다. 클라이언트 장치에는 보다 지속적인 예비 저장영역이 있어 일부 실패로부터 가장 중요한 데이터를 보호합니다.
기본적인 통신 링크 실패 이상의 실패 모드 매트릭스가 발생하면 문제점이 복잡해져 WebSphere MQ Telemetry Transport에 대한 스펙이 핸들링할 수 없을 정도로 심각하게 됩니다.
수신확인되지 않은 메시지를 다시 송신하기 전의 시간 지연(간격 재시도)은 응용프로그램마다 고유하며 프로토콜 스펙에 의해 정의되지 않습니다.