物联网协议Coap之Core和NetWork简介

待我称王封你为后i 2024-02-05 23:47 22阅读 0赞

##  ##

**目录**

前言

一、Coap的Core包

1、Coap对象

2、Message对象

3、Request对象

4、Response对象

二、Coap的NetWork调试

1、UDP运行模式

2、Network消息接收

3、Sender线程发送数据

三、总结

--------------------

## 前言 ##

在之前的博文中，对Californium中Coap的实现进行了简要的介绍，分别从Server和Client两端进行了基础介绍。对于面向连接的连接协议，一定是离不开网络层。本次将重点介绍Coap的Core核心实现以及网络层定义，虽然在Californium协议中，已经全面的实现了Coap协议。

本文将以Core包和NetWork包为主线，对Coap协议中，关于Californium框架的具体实现方式和代码编写进行讲解，希望对想了解Coap的实现朋友对其有更深入的了解。

## 一、Coap的Core包 ##

Coap的核心包定义了Coap适配的协议，请求协议头、响应对象等。主要包含Coap、Message、Option、Request、Response等几个对象。

### 1、Coap对象 ###

首先来看一下Coap对象的类图，如下图所示：

![2a11dc1a5c824d4d9da67542bec73b81.png][]

从上图可以看出，Coap类主要是一个常量类，其中包含了消息类型、请求类型编码、响应码、消息格式类型等。请注意这里是采用枚举属性的方式进行定义。比如消息类型的定义，部分代码已精简：

/**
    	 * CoAP defines four types of messages:
    	 * Confirmable, Non-confirmable, Acknowledgment, Reset.
    	 */
    	public enum Type {
    
    		/** The Confirmable. */
    		CON(0),
    
    		/** The Non-confirmable. */
    		NON(1),
    
    		/** The Acknowledgment. */
    		ACK(2),
    
    		/** The Reject. */
    		RST(3);
    
    		/** The integer value of a message type. */
    		public final int value;
    	}

以上四种消息类型表示如下：

<table> 
 <tbody> 
  <tr> 
   <td style="width:57px;">序号</td> 
   <td style="width:80px;">类型</td> 
   <td style="width:544px;">说明</td> 
  </tr> 
  <tr> 
   <td style="width:57px;">1</td> 
   <td style="width:80px;">CON</td> 
   <td style="width:544px;">需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。这有点像TCP，对方必须给确认收到消息，用以可靠消息传输。</td> 
  </tr> 
  <tr> 
   <td style="width:57px;">2</td> 
   <td style="width:80px;">NON</td> 
   <td style="width:544px;">不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。这适用于消息会重复频繁的发送，丢包不影响正常操作。这个和UDP很像。用以不可靠消息传输。</td> 
  </tr> 
  <tr> 
   <td style="width:57px;">3</td> 
   <td style="width:80px;">ACK</td> 
   <td style="width:544px;">&nbsp;应答消息，对应的是CON消息的应答。</td> 
  </tr> 
  <tr> 
   <td style="width:57px;">4</td> 
   <td style="width:80px;">RST</td> 
   <td style="width:544px;">复位消息，可靠传输时候接收的消息不认识或错误时，不能回ACK消息，必须回RST消息。</td> 
  </tr> 
 </tbody> 
</table>

请求方法枚举，这里主要定义了Coap请求方法编码，比如GET、POST、PUT等。关键代码如下：

/**
    	 * The enumeration of request codes: GET, POST, PUT and DELETE.
    	 */
    	public enum Code {
    
    		/** The GET code. */
    		GET(1),
    
    		/** The POST code. */
    		POST(2),
    
    		/** The PUT code. */
    		PUT(3),
    
    		/** The DELETE code. */
    		DELETE(4);
    
    		/** The code value. */
    		public final int value;
    	}

### 2、Message对象 ###

在通讯建立后，依赖于网络传输对象，Server端和Client端都会进行消息的传递。这是实际数据传递时所依赖的对象。这里重点介绍Message对象，大家可以重点查看Californium的源码来着重了解。首先来看一下Message对象的类图。

![331557f3b2e946c0b70dc1f014373e1b.png][]

在message对象中，定义了消息类型、mid、token、payload等信息。

**消息头（HEAD）**

第一行是消息头，必须有，固定4个byte。Ver : 2bit， 版本信息，当前是必须写0x01。T： 2bit， 消息类型，包括 CON, NON. ACK, RST这4种。TKL: 4bit，token长度， 当前支持0~8B长度，其他长度保留将来扩展用。

Code：8bit，分成前3bit（0~7）和后5bit（0~31），前3bit代表类型。 0代表空消息或者请求码， 2开头代表响应码，取值如下：

1 0.00 Indicates an Empty message

2 0.01-0.31 Indicates a request.

3 1.00-1.31 Reserved

4 2.00-5.31 Indicates a response.

5 6.00-7.31 Reserved

Message ID：16bit， 代表消息MID，每个消息都有一个ID ，重发的消息MID不变。token（可选）用于将响应与请求匹配。 token值为0到8字节的序列。 ( 每条消息必须带有一个标记, 即使它的长度为零）。 每个请求都带有一个客户端生成的token, 服务器在任何结果响应中都必须对其进行回应。token类似消息ID，用以标记消息的唯一性。token还是消息安全性的一个设置，使用全8字节的随机数，使伪造的报文无法获得验证通过。

**option**

请求消息与回应消息都可以0~多个options。 主要用于描述请求或者响应对应的各个属性，类似参数或者特征描述，比如是否用到代理服务器，目的主机的端口等。

**payload**

实际携带数据内容，若有，前面加**payload标识符“**0xFF”，如果没有payload标识符，那么就代表这是一个0长度的payload。如果存在payload标识符但其后跟随的是0长度的payload，那么必须当作消息格式错误处理。

![86c408d4bdf24c73b69e6cbc12371d4d.png][]

/** The Constant NONE in case no MID has been set. */
    	public static final int NONE = -1;
    	/**
    	 * The largest message ID allowed by CoAP.
    	 * <p>
    	 * The value of this constant is 2^16 - 1.
    	 */
    	public static final int MAX_MID = (1 << 16) - 1;
    
    	/** The type. One of {CON, NON, ACK or RST}. */
    	private CoAP.Type type;
    
    	/** The 16-bit Message Identification. */
    	private volatile int mid = NONE; // Message ID
    
    	/**
    	 * The token, a 0-8 byte array.
    	 * <p>
    	 * This field is initialized to {@code null} so that client code can
    	 * determine whether the message already has a token assigned or not. An
    	 * empty array would not work here because it is already a valid token
    	 * according to the CoAP spec.
    	 */
    	private volatile Token token = null;
    
    	/** The set of options of this message. */
    	private OptionSet options;
    
    	/** The payload of this message. */
    	private byte[] payload;
    
    	/**
    	 * Destination endpoint context. Used for outgoing messages.
    	 */
    	private volatile EndpointContext destinationContext;
    
    	/**
    	 * Source endpoint context. Used for incoming messages.
    	 */
    	private volatile EndpointContext sourceContext;
    
    	/** Indicates if the message has sent. */
    	private volatile boolean sent;
    
    	/** Indicates if the message has been acknowledged. */
    	private volatile boolean acknowledged;
    
    	/** Indicates if the message has been rejected. */
    	private volatile boolean rejected;
    
    	/** Indicates if the message has been canceled. */
    	private volatile boolean canceled;
    
    	/** Indicates if the message has timed out */
    	private volatile boolean timedOut; // Important for CONs
    
    	/** Indicates if the message is a duplicate. */
    	private volatile boolean duplicate;
    
    	/** Indicates if sending the message caused an error. */
    	private volatile Throwable sendError;
    
    	/** The serialized message as byte array. */
    	private volatile byte[] bytes;

### 3、Request对象 ###

与Http协议类似，Coap中，伴随着每一次的请求发送，势必也会有一个request对象。在request中进行信息的传递。因此，Requet也是继承自Message，其类图如下：

![7f634dc9c73241acab7f2a4dcd881f50.png][]

可以看到，在Reques对象中，针对Get、Put、Post、Delete等不同的方法也进行了定义。

/**
    	 * Convenience factory method to construct a POST request and equivalent to
    	 * <code>new Request(Code.POST);</code>
    	 * 
    	 * @return a new POST request
    	 */
    	public static Request newPost() {
    		return new Request(Code.POST);
    	}
    
    	/**
    	 * Convenience factory method to construct a PUT request and equivalent to
    	 * <code>new Request(Code.PUT);</code>
    	 * 
    	 * @return a new PUT request
    	 */
    	public static Request newPut() {
    		return new Request(Code.PUT);
    	}
    
    	/**
    	 * Convenience factory method to construct a DELETE request and equivalent
    	 * to <code>new Request(Code.DELETE);</code>
    	 * 
    	 * @return a new DELETE request
    	 */
    	public static Request newDelete() {
    		return new Request(Code.DELETE);
    	}

### 4、Response对象 ###

response对象与http也是类似的，跟B/S模式是一样的。有Client的请求对象，一定会对应有Server的Response对象。与Request一样，Response也是Message类的子类。

![acb914c57ebf491eab997eebb59e8f77.png][]

Reponse的方法相对比较简单，主要是将相应的信息放置到响应对象中，然后返回给前端。其主要的方法如下：

/**
    	 * Creates a response to the provided received request with the specified
    	 * response code. The destination endpoint context of the response will be
    	 * the source endpoint context of the request. Type and MID are usually set
    	 * automatically by the {@link ReliabilityLayer}. The token is set
    	 * automatically by the {@link Matcher}.
    	 *
    	 * @param receivedRequest the request
    	 * @param code the code
    	 * @return the response
    	 * @throws IllegalArgumentException if request has no source endpoint
    	 *             context.
    	 */
    	public static Response createResponse(Request receivedRequest, ResponseCode code) {
    		if (receivedRequest.getSourceContext() == null) {
    			throw new IllegalArgumentException("received request must contain a source context.");
    		}
    		Response response = new Response(code);
    		response.setDestinationContext(receivedRequest.getSourceContext());
    		return response;
    	}

由于篇幅有限，关于Core包的相关类介绍先到此，感兴趣的朋友可以下载源码后自己研究，以上将core包中比较重要的四个类进行讲解。下一步在讲解消息构造和方法运行时会更一步的涉及到这些类。因此着重介绍一下，以免不了解的读者不清楚具体的定义。

## 二、Coap的NetWork调试 ##

关于Coap的NetWork中的使用，准备结合动态运行过程进行讲解，主要结合Debug的方式，以类图这种分析方法不能完全的展示其调用过程和初始化步骤。比如，为什么说Coap默认是运行在UDP协议之下的，在系统运行时，其协议转换又是怎么工作的。下面将揭开这个面纱。

### 1、UDP运行模式 ###

众所周知，Coap默认试运行在UCP协议下的，我们来看一下其具体的定义。在CoapServer中创建CoapEndpoint时，可以看到以下的设置过程。

![c523a1a4d46c407ca4b0a578b2cb3051.png][]

在CoapEndpoint.java 中1285行，很清楚的看到这创建了UDPConnector连接器。

![6cd2c218c7c747538cc3e5c2afcb7562.png][]

![7e33c80781534a38bc5ffc9c530d45bc.png][]

![50fc59a79e724d61af020eb69a8cb770.png][]

### 2、Network消息接收 ###

在进行以上的对象定义之后，Coap基本就可以依赖于网络进行请求的运行了。启动方法

![8a7d8f4a285e4d4cbe72c4b995c9aa69.png][]

在这里，分别定义了发送线程集合和接收线程集合，用来保存接收和发送对象。receiverCount默认是16.

![bbb50d1f774f487a84cc79d918f0e0f5.png][]

### 3、Sender线程发送数据 ###

![773bf9b31f80471d8ccc7eb5eeb19fd7.png][]

在这里可以看到要发送的数据包信息，

![b6ae0bcb2caa4866a940cad03a0b5b81.png][]

### 4、Receiver接收响应 ###

![698b1e3b891e4a61a5294d976e917604.png][]

protected void work() throws IOException {
    			datagram.setLength(size);
    			socket.receive(datagram);
    			LOGGER.debug("UDPConnector ({}) received {} bytes from {}:{}",
    					new Object[]{socket.getLocalSocketAddress(), datagram.getLength(),
    						datagram.getAddress(), datagram.getPort()});
    			byte[] bytes = Arrays.copyOfRange(datagram.getData(), datagram.getOffset(), datagram.getLength());
    			RawData msg = RawData.inbound(bytes, new AddressEndpointContext(datagram.getAddress(), datagram.getPort()), false);
    
    			receiver.receiveData(msg);
    		}

在work方法中进行信息的转换，获取响应报文。通过转换后就可以获取以下报文体：

2.05
    {"Content-Format":"text/plain"}
    Hello CoAP!This is from Java coap server
    
    Advanced
    
    ==[ CoAP Response ]============================================
    MID    : 26037
    Token  : [6243fee1521b9e40]
    Type   : ACK
    Status : 2.05
    Options: {"Content-Format":"text/plain"}
    RTT    : 43333 ms
    Payload: 40 Bytes
    ---------------------------------------------------------------
    Hello CoAP!This is from Java coap server
    ===============================================================

## 三、总结 ##

以上就是本文的主要内容，本文将以Core包和NetWork包为主线，对Coap协议中，关于Californium框架的具体实现方式和代码编写进行讲解，希望对想了解Coap的实现朋友对其有更深入的了解。行文仓促，如有不当之处，请留言批评指正。

[2a11dc1a5c824d4d9da67542bec73b81.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/2296d717fa0741d2bb658c1d44ac32cb.png
[331557f3b2e946c0b70dc1f014373e1b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/29260a177edd479887117c1b6ae192ca.png
[86c408d4bdf24c73b69e6cbc12371d4d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/a4da23abfd2c4120ba5251ed49208e43.png
[7f634dc9c73241acab7f2a4dcd881f50.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/cfac4ea312de4597bf7ab5048450f925.png
[acb914c57ebf491eab997eebb59e8f77.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/778bb63c878447c9b812e16fa616124a.png
[c523a1a4d46c407ca4b0a578b2cb3051.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/da7ed1681d9e46f5a239ffaec1aab5b8.png
[6cd2c218c7c747538cc3e5c2afcb7562.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/29fcbebbf27f4221a7e63c51d0962d96.png
[7e33c80781534a38bc5ffc9c530d45bc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/537d9d319fee403f94ece0be65445ff4.png
[50fc59a79e724d61af020eb69a8cb770.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/84ae9ff94d3e44d8bb59b3456599d2ea.png
[8a7d8f4a285e4d4cbe72c4b995c9aa69.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/77d37e32b7474cfc89dff924e52f3506.png
[bbb50d1f774f487a84cc79d918f0e0f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/016b207cc05a49e3bb4460e5c2c37d24.png
[773bf9b31f80471d8ccc7eb5eeb19fd7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/b2d28add09a64ad48534c333fab8236e.png
[b6ae0bcb2caa4866a940cad03a0b5b81.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/fdf7e24226b64dfcaa7de076e4da1193.png
[698b1e3b891e4a61a5294d976e917604.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/ad17c30ddb8047ed930271218b3b26ed.png