CoAP学习笔记——服务器端繁忙时的处理请求流程
2014-01-02 21:07
218 查看
【原文链接】
更多CoAP文章请参考博文索引——【物联网学习笔记——索引博文】
根据前面的文章可以看出,CoAP是一个简单的请求响应机制,对于一个给定的请求便有一个相应的响应。很多时候,如果服务器不能立即响应一个CON请求,服务器只能返回一个空应答,这个空应答使得客户端停止重传CoAP请求。但是一些时间过去之后,服务器端准备好了上一个CON请求的响应,此时服务器向客户端发送一个CON请求,该CON请求需要客户端确认。在服务器侧,此时发送的CON请求中的Token标记必须和客户端发送给服务器的CON请求中的Token标记完全一致。这也是Token标志和序列号使用不同的地方。下面是流程的详细描述:客户端发送一个CON请求
此时服务器无法返回。如果服务器无法迅速响应,客户端会重复发送CON请求。为了避免这种情况,服务器会发送一个空应答。
当客户端收到了一个空应答,而空应答中的消息ID和CON请求中的消息ID相同,那么客户端可以便会理解,服务此时正忙,会在一定时间之后通过CON请求的方式返回内容。
当服务器准备好数据时便尝试发送给客户端,服务器会构造一个CON请求并复制原先的CON请求中的Token标记。
客户端收到一个来自服务器的CON请求之后返回一个应答,如果客户端不及时返回应答,服务器会认为上一个CON请求丢失并会尝试重新发送CON请求。
更多CoAP文章请参考博文索引——【物联网学习笔记——索引博文】
根据前面的文章可以看出,CoAP是一个简单的请求响应机制,对于一个给定的请求便有一个相应的响应。很多时候,如果服务器不能立即响应一个CON请求,服务器只能返回一个空应答,这个空应答使得客户端停止重传CoAP请求。但是一些时间过去之后,服务器端准备好了上一个CON请求的响应,此时服务器向客户端发送一个CON请求,该CON请求需要客户端确认。在服务器侧,此时发送的CON请求中的Token标记必须和客户端发送给服务器的CON请求中的Token标记完全一致。这也是Token标志和序列号使用不同的地方。下面是流程的详细描述:客户端发送一个CON请求
此时服务器无法返回。如果服务器无法迅速响应,客户端会重复发送CON请求。为了避免这种情况,服务器会发送一个空应答。
当客户端收到了一个空应答,而空应答中的消息ID和CON请求中的消息ID相同,那么客户端可以便会理解,服务此时正忙,会在一定时间之后通过CON请求的方式返回内容。
当服务器准备好数据时便尝试发送给客户端,服务器会构造一个CON请求并复制原先的CON请求中的Token标记。
客户端收到一个来自服务器的CON请求之后返回一个应答,如果客户端不及时返回应答,服务器会认为上一个CON请求丢失并会尝试重新发送CON请求。
相关文章推荐
- ASP.NET 3.5核心编程学习笔记(1):ASP.Net页面请求处理流程
- [linux驱动]linux块设备学习笔记(四)——请求处理
- Dynamic CRM 2013学习笔记(三十三)自定义审批流4 - 规则节点 -有分支的流程处理
- Struts2学习笔记之struts.xml配置常量和Action处理流程
- HTTP学习之一:Http 请求处理流程
- spring学习笔记:spring mvc的处理流程
- Linux icmp 学习笔记 之二 icmp数据处理流程
- Windows内核学习笔记(三)-- IRP请求处理及完成机制
- springMVC学习笔记-请求处理&springMVC form标签
- nginx学习笔记六(Nginx事件框架处理流程)
- Akka学习笔记:Actor消息处理-请求和响应(1)
- 黑马程序员_学习笔记24_请求处理响应图解
- Java Web 学习笔记之十二:JBoss RestEasy处理跨域OPTIONS请求方式
- Akka学习笔记:Actor消息处理-请求和响应(2)
- Akka学习笔记:Actor消息处理-请求和响应(2)
- Servlet学习笔记_04_servlet处理流程
- Nginx学习笔记之事件驱动框架处理流程
- Linux IGMP PROXY 学习笔记 之二 igmp proxy的处理流程分析
- stuts2学习笔记------指定需要struts2处理的请求后缀&细说常量定义&常用常量介绍
- Django中间件处理流程学习笔记