내 서버는 측정 세트를 표시하지만 아직 읽지 않은 설정 만 표시합니다. 이 목적을 위해 GET 요청 후에 방금 보낸 측정 값을 버리는 단일 리소스 /new을 구현했습니다. 요청자가 요청의 수신을 확인하기를 서버가 어떻게 기다리게 할 수 있습니까?CoAP 확인 응답
나는 이것이 CoAP 의미론을 충분히 존중하지 않지만 여전히 유용 할 것이라는 것을 알고있다. 서버가 실제로 일부 클라이언트가받은 판독 값 만 삭제한다는 의미입니다.
의 상단에 구독 할 수 있습니다 (당신은 당신이 사용 했하는 방법 말할 수있는 경우에? 난 관심). 어쨌든 토큰 (https://tools.ietf.org/html/rfc7252#section-5.3.1)을 사용해야한다고 생각합니다. 이것은 내가 할 일입니다 :
1) 클라이언트가 메시지 토큰을 포함하는 서버에 CON 요청을 보냅니다.
2) 서버가 동일한 토큰으로 빈 ACK를 보냅니다.
3) 서버는 동일한 토큰 및 측정 세트를 포함하는 CON 응답을 보냅니다.
4) 클라이언트는 동일한 토큰으로 빈 ACK를 전송합니다.
5) 서버에서 이제 읽기 리소스를 삭제할 수 있습니다.
서버는 일단 자원을 읽으면 자원을 삭제할 수 있습니다.
당신은 또한 /의 coap-MQ에 게시에 대한 DRAF을 살펴 당신은 아마 그것을 해결의 coap
아니요, 읽는 것만으로는 충분하지 않습니다. 서버는 클라이언트가 실제로 응답을 받았는지 확인해야합니다. CoAP-MQ와 관련해서는 이것이 매력적인 해결책 인 것처럼 보이지만 광범위하게 구현 된 것은 아니라고 생각합니다. 일반적으로 MQTT와 같은 pub/sub 모델은 제공 할 수있는 QoS 보장 때문에 사용 사례에 더 적절할 수 있습니다. – bbc
Ok 서버에서 자원을 절약하고 클라이언트가 클라이언트를 소비하는 실수를 범했습니다. 일단 클라이언트가 소비하면 클라이언트는 리소스를 삭제해야합니다. –
좋아요, 그렇게 할 수는 있지만 더 많은 메시지가 포함되어 센서에 배터리가 소모 될 수 있습니다. 내가 찾고있는 것은 근본적으로 (서버의 ack을 따라 보내지는) 피기 백이고 확인 가능한 (서버는 클라이언트가 ack를 보낼 때까지 기다릴 것이다) 응답이다. 이것이 불가능할 경우 솔루션은 받아 들일 수있는 대안입니다. – bbc
CoAP가 그렇게 할 수 있다는 것은 분명하지 않습니다. 토큰은 두 쌍의 요청 - 응답이 아닌 요청과 응답을 일치시키는 것을 의미합니다. 제 경우에는 확인 가능한 POST 요청으로 서버가 클라이언트와의 통신을 시작하도록 선택했습니다. – bbc
메시지를 고유하게 식별하고 중복 검색에서 서버를 돕는 데 사용되는 메시지 ID와 달리 토큰은 메시지 식별자가 다르더라도 논리적으로 관련된 단일 트랜잭션 세트에 참여하는 메시지를 상호 연관시키는 데 사용됩니다. 여기에서 예를 찾을 수 있습니다 (그림 20). https://tools.ietf.org/html/rfc7252#page-108 – Jiloc
메시지 교환을 최소화하기 위해 클라이언트가 NON 요청을 사용하도록 내 대답을 편집했습니다. – Jiloc