Confirmable message — CoAP protokolida qabul qiluvchi tomonidan acknowledgement talab qiladigan xabar turidir. CoAP UDP kabi ishonchsiz datagram transportida ishlashi mumkinligi sabab confirmable, ya’ni CON xabar qayta uzatish va tasdiqlash orqali yetkazilish ehtimolini oshiradi. Bu TCPdagi to‘liq reliable byte stream emas, balki bitta CoAP message uchun mexanizmdir.
Xabar almashinuvi
Client CON request yuboradi. Server tez javob bera olsa response ni ACK xabari ichida qaytaradi; bu piggybacked response deyiladi. Serverga ko‘proq vaqt kerak bo‘lsa bo‘sh ACK yuborib, request olinganini bildiradi. Keyin alohida CON response jo‘natadi va client uni ACK bilan tasdiqlaydi.
Qabul qiluvchi message ni qayta ishlay olmasa Reset, ya’ni RST yuborishi mumkin. ACK requestning biznes amali muvaffaqiyatli bo‘lganini har doim anglatmaydi; response code natijani bildiradi.
Qayta uzatish
Sender ACK kelmasa timeoutdan keyin CON message ni qayta yuboradi. Timeout random boshlang‘ich intervaldan olinib, odatda exponential backoff bilan oshadi. Maksimal retransmit soni tugagach xabar failed hisoblanadi. Aniq default qiymatlar CoAP spetsifikatsiyasi va implementation konfiguratsiyasiga bog‘liq.
UDP datagram kechikishi yoki ACK yo‘qolishi mumkin. Server bir xil requestni qayta oladi, shuning uchun duplicate detection kerak. Qayta uzatish tarmoq congestioni paytida yukni oshirmasligi uchun CoAP NSTART va probing cheklovlariga ega.
Message ID va token
16-bit Message ID ACK/RSTni xabar bilan bog‘lash va yaqin vaqt oralig‘idagi duplicate datagramlarni tanish uchun ishlatiladi. Token esa request va response ni, ayniqsa separate response holatida, bog‘laydi. Message IDni application transaction identifikatori sifatida uzoq muddat saqlash noto‘g‘ri, chunki u aylanishi mumkin.
Duplicate CON requestga server avvalgi ACKni qayta yuborishi mumkin. Agar non-idempotent amal birinchi urinishda bajarilgan bo‘lsa duplicate qayta bajarilmasligi kerak. CoAP duplicate detection oynasi transport darajasida yordam beradi, lekin uzoq application operation uchun alohida idempotency talab qilinishi mumkin.
CON va NON tanlovi
Non-confirmable, ya’ni NON message ACK talab qilmaydi. Tez-tez yuboriladigan sensor telemetriyasida keyingi sample oldingisini almashtirsa NON tarmoq xarajatini kamaytiradi. Muhim command yoki kam uchraydigan holatda CON tanlanishi mumkin.
CON ishlatish deliveryni mutlaq kafolatlamaydi: retry tugashi, receiver offline bo‘lishi yoki response yo‘qolishi mumkin. Application timeout va kompensatsiya holatini belgilaydi. Multicast requestlar odatda ACK storm xavfi sabab boshqa semantikaga ega.
Xavfsizlik
DTLS yoki OSCORE message confidentiality va integrityni ta’minlaydi. ACKning mavjudligi sender identitysi tasdiqlangan degani emas. Hujumchi soxta ACK, replay yoki resource exhaustionga urinishi mumkin; security context, replay himoyasi va rate limit ishlatiladi.
Response caching
CoAP response cacheable bo‘lishi mumkin. Duplicate CON requestga server applicationni qayta bajarmasdan oldingi response yoki ACKni qaytaradi. Cache key method, URI va relevant optionlarni hisobga oladi. Observe notificationlarda confirmable delivery subscriberning bitta notificationni olganini tekshiradi, ammo keyingi state allaqachon o‘zgargan bo‘lishi mumkin.
Proxy CON va ACKni har transport hop doirasida boshqarishi ehtimol. End-to-end application natijasi proxy acknowledgementi bilan teng emas. Token va response code clientga mantiqiy exchange holatini ko‘rsatadi.
Client response tokenini ham tekshiradi.
Bog‘liq tushunchalar
CoAP, Acknowledgement, Non-confirmable message, Message ID, Token, Retransmission, OSCORE