本文的主要目的是描述标识符追溯协议（IDTP）的设计规范。Busilet4j项目是IDTP的一个参考实现，展示了规范如何实现。Busilet4j提供了一些API供开发人员用Java语言编写IDTP服务器和IDTP客户端程序。因此，本文可能会使用Busilet4j的实现来描述IDTP规范的细节。

注意：Busilet4j项目将提供一个名为Busilet4net的C#语言实现，支持开发人员用C#语言编写IDTP服务器和IDTP客户端程序。为此，Busilet4j中的一些Java代码的编写方式将更容易转换为C#代码。

1.2 目标

物联网（IOT）可以理解为“万物互联”，它是一个由世界万物之间的各种通信技术组成的庞大网络。从物联网的角度来看，一个事物可以被视为信息提供者（事物的信息，或者当事物是传感器时的数据），因为客户端可以看到提供者而不是事物本身。一个事物也可以被视为一个动作的执行者（当事物连接到继电器以打开或关闭灯时）。在本文中，事物可以是现实世界中的事物，也可以是虚拟世界中的事物。

因此，（1）一切事物都应该有一个统一的标识符来识别现实世界或虚拟世界中的任何事物；（2）一切事物都应该有一个通用的通信通道与其他事物通信，以达到任何地方。IDTP的目标是为事物之间的通信提供一个通用的解决方案，即一种识别事物的方法（UTID，通用可追溯标识符）和一种交换事物信息（IDTP，标识符追溯协议）的协议。

此外，UTID和IDTP是如此通用和普遍，它们为计算架构提出了新的数据通信通道，并可以应用于许多其他领域，如数据库管理、分布式计算、云计算。

1.3 本文的读者

读者分为三类

物联网、Web服务、云计算和普适计算的学术研究人员
维护Busilet4j或开发新的IDTP实现的开发人员
使用Busilet4j API开发IDTP应用软件（服务器或客户端软件）的开发人员

1.4 为什么需要新协议？

物联网中存在各种广泛使用的编码系统和通信协议。EPC和Web服务是推动物联网发展的典型代表。然而，任何技术都有其固有的缺点。例如，EPC主要用于在生产和物流过程中识别产品，是该情境下的最佳编码系统。但在物联网时代，产品在生产后会经历流通、仓储和消费过程。同一产品可能需要在不同过程中由不同公司使用不同的编码系统进行记录，以便在不同公司提供和共享同一产品在不同状态下的信息。例如，没有公司愿意使用最初为识别产品设计的EPC系统来识别其固定资产。问题在于这些不同公司和不同编码系统之间的通信。结果是生产者难以追溯其出厂流程，消费者除了生产者之外，也难以找到流通过程中的信息。另一个例子是互联网的关键技术IP协议。但它不能应用于由没有IP地址的传感器组成的网络。

总的来说，我们需要一个更开放、更通用的编码系统和协议。本规范提供了一个独立于任何行业或任何情境的开放式解决方案。

1.5 术语

UTID（通用可追溯标识符）：它是用于标识事物的唯一标识符。

IDTP（标识符追溯协议）：它是用于交换事物信息的通信协议。它是在开放系统互连（OSI）模型中的应用层协议。

Busilet（小业务）：它是提供事物信息的业务逻辑。其名称来源于applet和servlet。

Request（请求）：它是一个（Java）类，用于表示访问事物信息时使用的请求参数。它封装了要访问的事物的UTID以及所有其他请求参数。

Response（响应）：它是一个（Java）类，用于表示返回给请求者的事物信息。它封装了事物的所有相关信息。

Namespace（命名空间）：它用于对Busilet进行分组，并避免Busilet的命名冲突。它与Java语言中的package和C#语言中的namespace完全相同。它也与Web服务中的namespace相同，但顺序相反。

IDTP Server（IDTP服务器）：它是一个提供UTID标识的事物信息的节点。在接受请求后，它将执行匹配的Busilet中的业务逻辑，然后返回一个响应，包含UTID标识的事物信息给请求者。

IDTP Client（IDTP客户端）：它是发送请求以获取请求中UTID标识的事物信息的节点。它期望从IDTP服务器接收响应，并且不关心Busilet中的业务逻辑。

IDTP node（IDTP节点）：IDTP节点或本文中的节点是指IDTP服务器或IDTP客户端。一个节点通常在大多数时候充当服务器和客户端。

Node name（节点名称）：每个节点都应该有一个名称，该名称是全局唯一的，由DNS名称和一个子域名组成。例如：“n1.sample.test”。

Trace（追溯）：它是追溯UTID标识事物位置并将其请求转发到目标IDTP服务器的过程。响应将以相同的路由方式返回给请求者。之所以称为trace（追溯）是为了避免与常用词“forward”（转发）混淆。

Trace gate（追溯网关）：负责请求的追溯（转发）的节点。它是一个追溯请求并可选择进行数据格式转换的IDTP服务器。它类似于互联网中的网关，但在属于应用层的IDTP协议中工作。它可以被视为一个IDTP网关。

Trace bridge（追溯桥）：当追溯到IDTP协议边界之外的事物时，需要一个桥梁来连接事物和IDTP。类似于互联网中的桥梁，追溯桥是一个IDTP节点，通过任何可用的通信通道（如ZigBee、Bluetooth、CAN或串行端口）连接到一个非IDTP节点。桥梁还需要与非IDTP节点协商通信方法和交换格式。

IDTP domain（IDTP域）：一组具有相同操作规则和策略的IDTP节点，通常由同一组织拥有。因此，所有者可以为IDTP域中的追溯制定统一的规则和策略。IDTP域内的追溯独立于IP地址或DNS名称，与IP转发不同。

IDTP domain name（IDTP域名称）：每个IDTP域都应该有一个名称，该名称是IDTP域的DNS名称，并由IDTP域中的所有节点共享。例如：“id.sample.test”。

IDTP port number（IDTP端口号）：IDTP于2011年在IANA注册了其端口号25604。建议将此端口号作为IDTP的默认端口号。

Local processing（本地处理）：表示请求者和响应者在同一进程中，即相同的端口号。

Remote processing（远程处理）：表示请求者和响应者不在同一进程中，即同一机器上的不同机器或不同端口号。

1.6 与其他技术的比较

1.6.1 与Web服务的比较

Web服务是与IDTP相似的通信协议之一。Web服务是一种标准化且成熟的协议，在许多领域得到广泛应用。但IDTP和Web服务之间存在一些差异。

轻量级：IDTP是一种轻量级协议，不仅适用于RPC（远程过程调用），也适用于本地调用，其成本仅在于创建三个类（Request、Response和Busilet）。它允许程序关注业务逻辑，而无需关注远程或本地进程。否则，不建议在本地调用中使用Web服务。
普适性：对于IDTP，对设备计算能力的要求较低，因此应用领域可以扩展到嵌入式系统和智能设备。而Web服务需要更多的计算能力，限制了其应用。
封装：对于IDTP，所有参数都封装在请求和响应对象中。但Web服务可能有一个以上的请求参数，这增加了复杂性。
双层路由：IDTP中有两层路由，一层是TCP/IP提供的IP路由，另一层是IDTP域内的IDTP追溯，这使得IDTP协议更加灵活方便，适用于物联网。
与UTID绑定：IDTP必须与UTID协同工作。没有UTID的配合，IDTP将失去其价值。
安全性：IDTP内置AES加密算法和RSA公钥密钥交换技术的加密通信。此外，IDTP还为计算能力较弱但在相对安全环境（如IDTP域内的局域网）中的设备提供XOR加密算法。
会话：IDTP还提供内置会话功能，类似于HTTP会话。
应用范围：IDTP和Web服务相似，但应用范围略有不同。IDTP主要应用于物联网。

另一方面，IDTP与Web服务兼容。IDTP采用WSDL定义文件来定义IDTP Busilet，并引入UDDI发现机制。IDTP可以与Web服务通信，反之亦然。此外，IDTP可以使用Web服务服务器的WSDL定义文件生成IDTP busilet、请求和响应类，Web服务也可以使用IDTP服务器的WSDL定义文件生成Web服务服务器或客户端代码。总之，IDTP和Web服务可以互补并共同发展。

为了与Web服务兼容，IDTP的设计可能需要一些特殊的考虑，例如，参数的名称专门为与Web服务兼容而设计。

1.6.2 与EPC的比较

电子产品代码（EPC）被设计为一种通用标识符，为世界上任何物理对象提供唯一身份。它是物联网中广泛使用的一项主要技术标准。与EPC一样，UTID也是一个通用标识符系统，有许多相似之处。以下是它们之间的一些区别：

开放性：UTID是开放的，因为它直接基于DNS构建。任何拥有DNS名称的组织和个人都可以拥有自己的UTID系统并使用它，而无需付出更多努力。EPC也是开放的，但需要注册并拥有ONS系统才能将EPC解析为DNS。
普适性：UTID设计用于识别现实世界或虚拟世界中的任何事物，具有灵活可变的长度代码格式。但EPC设计用于识别物理对象，并具有严格的代码格式。
双层路由：EPC和UTID都有双层路由。但是，它们是不同的。EPC的双层路由都是TCP/IP路由，中间有ONS。而UTID的双层路由包括TCP/IP路由和IDTP追溯。
基于字符：EPC是基于位的，固定长度。UTID是基于字符的，可变长度。因此，UTID是一种偏码系统，其效率可能稍低。但优点是灵活且可读。随着计算能力的快速增长，效率将变得不那么重要。

总的来说，UTID和EPC是针对不同需求并在不同领域应用的。我们希望UTID能与EPC互补，IDTP能与Web服务互补，它们都将成为物联网中的重要技术并快速发展。

1.7 历史

IDTP和UTID的概念于2011年4月提出，灵感来自于朋友提出的事物邮件系统。2011年，我和朋友发表了两篇学术论文：

Neng-Geng Huang, Bing-Liang Zhang, Zhi-Yuan Huang (2011): Concept and design of a things mail system, Signal Processing, Communications and Computing (ICSPCC), 2011 IEEE International Conference on. DOI: 10.1109/ICSPCC.2011.606174
Neng-Geng Huang, Bing-Liang Zhang (2011): Design and implementation of a universally traceable coding system, Computer Application and Software, Vol 28(11):271-275

从2011年5月到2013年8月，IDTP和UTID的架构和设计经历了无数次修改，Busilet4j项目也反复重新设计和修改，以反映IDTP和UTID的变化。我于2011年8月9日向IANA注册了IDTP端口号25604。Busilet4j项目也于2012年6月作为开源软件发布在sourceforge.net上。URI是http://sourceforge.net/projects/busilet/。

在各种开发阶段，Busilet4j API已应用于近两年的实际项目中。这四个项目如下：

事物邮件系统：这是激发IDTP和UTID概念的项目。该项目已投入使用，并在Linux服务器和Android终端上运行。它实现了已在上述两篇论文中发表的所有设计目标。但不幸的是，由于财务问题，它并未成功推广。
网络锁项目：这是一个企业定制项目，已在Android终端上运行两年。
作物施肥项目：这也是一个企业定制项目，在Windows上运行。
作物种子追溯项目：这是一个复杂项目，包括种子包装、批发、零售和种子信息追溯。它在Windows、Web服务器、种子包装时的车间Android终端以及仓库中的WinCE PDA上运行。IDTP是这些设备之间的通信协议，UTID用于标识种子包装和追溯种子信息。

作为一所大学的副教授，我指导了三组学生使用IDTP和UTID技术参加国家级比赛：

2012年全国职业院校技能大赛（物联网技术应用类）：我的团队获得二等奖（在该类别中排名第五）。我们设计了使用IDTP和UTID技术的系统。
2012年第17届国际ICT创新服务竞赛（台湾）：我的团队获得二等奖（亚太交流组排名第三）。这是事物邮件系统的改进版本，展示了IDTP和UTID的所有理念和设计。
2013年第四届Android应用开发中国大学生挑战赛：该项目仅采用IDTP作为通信通道，并未展示IDTP和UTID的理念和设计。

Busilet4j项目自2013年10月起发布在https://code.google.com/p/busilet/。

1.8 总结

在这两年半的时间里，本文作者对IDTP和UTID进行了无数次改进、重新设计和修订，但仍不满意。因此，Busilet4j没有在sourceforge.net上发布新版本。当最后一项关键技术于2013年9月解决后，IDTP规范被重写，Busilet4j项目被重新设计、重构和重写，主要涉及追溯、加密和会话。

现在，我很高兴地宣布，在近三年的努力之后，该项目将以新的面貌发布，为开源软件论坛做出贡献。

2 导师示例

让我们通过一个导师示例来认识IDTP和UTID。一家名为“sample.test”的公司希望为其产品提供信息查询功能。信息位于一个名为“db”的地方。有两个产品，编号为101和102，将由用户查询。

该公司构建了一个IDTP服务器来提供信息查询。客户端应从IDTP客户端发送查询以获取产品信息。因此，我们的导师示例中应该有一个IDTP服务器项目和一个IDTP客户端项目。

2.1 UTID的设计

作为产品生产者，公司“sample.test”应为其产品分配唯一的标识符。在本导师示例中，两个产品在UTID形式下被分配了“101@db#sample.test”和“102@db#sample.test”。

2.2 IDTP服务器的设计

我们将使用Eclipse来开发项目。一个IDTP项目应该有一个用于log4j的配置文件，例如log4j.properties。

第一步是创建一个名为“IdtpServer”的新Java应用程序项目，并将busilet4j_0.95.jar和一些依赖的jar文件包含到项目的Java构建路径中。

busilet4j_0.95.jar
commons-logging-1.1.1.jar
jackson-all-1.8.7.jar
jackson-xml-databind-0.6.1.jar
log4j-1.2.16.jar
mysql-connector-java-5.1.6-bin.jar
org.json-2013-2-19.jar
stax2-api-3.1.1.jar

第一步是创建busilet、请求和响应类。您可以手动创建它们，也可以使用工具创建。在该项目中创建一个类，并包含以下代码：

import org.utid.UtidException;
import org.utid.tool.BusiletTool;

public class BusiletGen {
	public static void main(String[] args) throws UtidException {
		new BusiletTool().createEmptyBusilet("test.sample", "Product");
	}
}

createEmptyBusilet()方法将为您创建busilet、请求和响应类。这些类将在名为“utid.test.sample”的包中，其中utid由工具自动添加，以表示该类是UTID类。这三个类分别命名为ProductRequest、ProductResponse和ProductBusilet。现在是时候对这三个类进行一些小的修改了。

第一个类是请求类，名为ProductRequest，外观如下：

package utid.test.sample;

import org.utid.busilet.IdtpRequest;

public class ProductRequest extends IdtpRequest {
	public String sender;  // the sender’s name
}

请求类应继承IdtpRequest类。

第二个类是响应类，名为ProductResponse，它封装了两个属性：产品名称和价格，返回给请求者。

package utid.test.sample;

import org.utid.busilet.IdtpResponse;

public class ProductResponse extends IdtpResponse {
	public String name = "Unkown"; // product name
	public double price = -1; // price
	public String remark = ""; // more information
}

响应类应继承IdtpResponse类。

第三个类是名为ProductBusilet的busilet类，它接收一个请求并返回一个响应作为对请求者的结果。

package utid.test.sample;

import org.utid.Utid;
import org.utid.UtidException;
import org.utid.busilet.BusiletExecutable;
import org.utid.busilet.IdtpRequest;
import org.utid.busilet.IdtpResponse;

public class ProductBusilet implements BusiletExecutable {

	@Override
	public IdtpResponse doBusiness(IdtpRequest idtpRequest)
			throws UtidException {
		// prepare request and response object
		ProductRequest request = (ProductRequest) idtpRequest;
		ProductResponse response = new ProductResponse();

		//business logic: query the information and set to response object.
		Utid utidObj = new Utid(request.getUtid());
		if (utidObj.getId().equals
		("101")) {  // the product number is stored in UTID
			response.name = "Pen";
			response.price = 12;
		} else if (utidObj.getId().equals("102")) {
			response.name = "Bag";
			response.price = 19;
		}
		response.remark = "Hello, " + request.sender;

		// return the response object
		return response;
	}
}

busilet类应实现BusiletExecutable接口并实现doBusiness()方法。

最后一步是设置一个IDTP服务器，通过创建一个名为Server的类并包含以下代码：

package test.sample.server;

import org.utid.UtidException;
import org.utid.idtp.IdtpConfig;
import org.utid.idtp.IdtpServer;

public class Server {

	public static void main(String[] args) throws UtidException {
		// IDTP configuration
		IdtpConfig.domainName = "sample.test";
		IdtpConfig.nodeName = "n1.sample.test";

		// IDTP server trace configuration
		IdtpConfig.addTracingTrack("@db#sample.test");

		// Start IDTP server
		IdtpServer.startTcpServer();
	}
}

代码中的关键是IDTP服务器的追溯配置，它指示服务器接受以“@db#sample.test”结尾的任何UTID的请求。服务器启动运行后，将监控IDTP的默认端口号25604，并输出运行信息，如下所示：

*******************************************
*                                        
*  tcp/ws/http initialize success        
*    domainName: sample.test
*    accept utidsuffix: @db#sample.test
*    node name: n1.sample.test
*    port number: 25604
*                                       
*******************************************

现在IDTP服务器正在运行并等待传入的请求。

2.3 IDTP客户端的设计

创建另一个名为IdtpClient的Java应用程序项目，包括与服务器项目相同的jar文件。不要忘记log4j的配置文件log4j.properties。

busilet4j_0.95.jar
commons-logging-1.1.1.jar
jackson-all-1.8.7.jar
jackson-xml-databind-0.6.1.jar
log4j-1.2.16.jar
mysql-connector-java-5.1.6-bin.jar
org.json-2013-2-19.jar
stax2-api-3.1.1.jar

第一步也是编写请求和响应类，但不包括busilet类。我们应该从服务器项目复制这两个类，以确保它们完全相同。服务器和客户端中的请求和响应类应完全相同，包括包名、类名、属性名和数据类型。否则将无法正常运行。客户端不需要busilet类，因为客户端不关心业务逻辑。

第二步是创建一个名为Client的客户端类，并包含以下代码：

package test.sample.client;

import org.utid.UtidException;
import org.utid.busilet.IdtpResponse;
import org.utid.idtp.BusiletDispatcher;
import org.utid.idtp.IdtpConfig;

import utid.test.sample.ProductRequest;
import utid.test.sample.ProductResponse;

public class Client {

	public static void main(String[] args) throws UtidException {
		// IDTP configuration from another company, which make the request.
		IdtpConfig.domainName = "demo.test";
		IdtpConfig.nodeName = "n0.demo.test";

		// IDTP Client trace configuration
		IdtpConfig.addTracingParam4Tcp("mytcp", "*", 0);
		IdtpConfig.addTracingTrack("@db#sample.test", "127.0.0.1", "mytcp");

		// Prepare request object
		String utid = "101@db#sample.test";
		ProductRequest request = new ProductRequest();
		request.setUtid(utid);
		request.sender = "Bella.";

		// Sending the request
		IdtpResponse response = BusiletDispatcher.doBusilet(request);

		// Deal with the response
		if (response.isOk()) {
			ProductResponse priceResponse = (ProductResponse) response;
			System.out.println("Name = " + priceResponse.name);
			System.out.println("Product = " + priceResponse.price);
			System.out.println("Remark = " + priceResponse.remark);
		} else {
			System.out.println("Error status==" + response.getStatus());
		}
	}
}

代码中的关键也是追溯配置，它指示所有UTID以“@db#sample.test”结尾的请求将通过名为“mytcp”的追溯参数被追溯到127.0.0.1（此机器同时充当服务器和客户端），该参数定义为使用TCP默认端口号25604并匹配任何命名空间（符号星号*表示匹配任何命名空间）。

上述代码可分为三个步骤：

准备一个ProductRequest类实例并设置一些参数，特别是UTID的正确值。
通过调用BusiletDispatcher.doBusilet()方法发送请求。
处理响应。

2.4 运行

当服务器仍在运行时运行客户端代码，您将从控制台读取输出：

2013-10-03 19:44:56,624  INFO (TraceGate.java:46) - 
Accept request from local: idtp:0.9:1;utid:101@db#sample.test;ns:utid.test.sample;name:Product
2013-10-03 19:44:56,660  INFO (TraceGate.java:296) - Forward through TCP[n0.demo.test]: idtp:0.9:1;utid:101@db#sample.test;ns:utid.test.sample;name:Product;hop:1;hops:n0.demo.test
2013-10-03 19:44:56,661 DEBUG (TcpRequest.java:33) - Sending TCP/WS reqeust==> 127.0.0.1:25604
2013-10-03 19:44:56,667 DEBUG (TcpRequest.java:100) - ==RequestData==idtp:0.9:1;utid:101@db#sample.test;ns:utid.test.sample;name:Product;len:34;hop:1;hops:n0.demo.test
{"_attri_":"{}","sender":"Bella."}

2013-10-03 19:44:56,669 DEBUG (TcpRequest.java:112) - ==ResponseData==idtp:0.9:1;
code:200 OK;len:67;hop:1;hops:n1.sample.test
{"_attri_":"{}","name":"Pen",
"price":12.0,"remark":"Hello, Bella."}

Name = Pen
Product = 12.0
Remark = Hello, Bella.

它显示了查询结果。您也可以从控制台读取服务器的输出：

2013-10-03 19:45:45,253 DEBUG (TcpServer.java:389) - Accept TCP request [3].
2013-10-03 19:45:45,253  INFO (TraceGate.java:73) - Accept request by TCP
[n1.sample.test]: idtp:0.9:1;utid:101@db#sample.test;ns:utid.test.sample;
name:Product;len:34;hop:1;hops:n0.demo.test

这非常简单，就像一个导师示例一样，演示了设置IDTP客户端和IDTP服务器之间通信的基本过程。对于更复杂的情况，服务器和客户端的UTID和追溯配置应该有更复杂的设计。

3 UTID标识符

IDTP是一种访问事物信息的协议，事物应该由UTID标识。因此，我们先讨论UTID规范。

物联网的运行基于事物的识别，事物应该有一个或多个标识符。一个事物可能处于不同的阶段，位于不同的地方，属于不同的公司，被视为不同的状态，并且可能需要不同的标识符来识别这些差异。因此，我们需要一种通用的、简单的编码方法来识别任何事物并使它们能够通信到任何地方。

3.1 设计原则

唯一性：这是基本原则。每个标识符唯一地标识现实世界或虚拟世界中的一个事物。但是，一个事物可能有一个或多个标识符来从不同方面识别它。
可追溯性：标识符应包含追溯其信息所需的必要消息。即谁拥有它以及它在哪里。
通用性：标识符应能够应用于任何事物。这意味着它应该是简单、开放且与当前技术兼容的。

3.2 UTID

3.2.1 定义

当我们在物联网中追溯事物时，我们需要知道事物是什么，谁拥有事物，事物在哪里，以及如何处理事物的信息。这就是3WH（What, Who, Where, How）。IDTP协议中的事物标识符（UTID）应具有以下基本属性：

Dns：它标记了事物的所有者。每个事物必须有一个所有者，这不是法律上的所有者，而是能够提供事物信息的人。如果一个事物没有合法所有者，负责提供事物信息的人就是事物的所有者。所有者有两个职责：
1. 为事物分配UTID；
2. 承诺提供事物的信息。
Location（位置）：它表示事物所在的位置，实际上是能够提供事物信息的IDTP服务器的位置。
Catalog（目录）：同一目录中的所有事物应该具有相同类型的信息，以便我们可以用相同的方式处理信息。目录反映了事物信息的*数据格式*，或数据格式标准。这些数据格式标准可能是公司标准、行业标准或国际标准。
Id：它是具有或不具有意义的唯一名称，例如序列号、UUID、用户名或数据库中的主键。

现在，我们定义UUID的格式：

id$catalog@location#dns

UTID的一个示例如101$sensor@room102#sample.test，可以读作“sample.test”中“room102”里的“101”。

表 1 UTID组件

组件 (Component)	分隔符	示例	可用字符	最大长度	可选
dns	#	sample.test	DNS规范（仅小写字母）	64	必需
location	@	room102	a-z_0-9.-	64	可选
catalog	$	sensor	a-z_0-9.-	64	可选
id		101	a-z_0-9.-~	64	可选

表 1 UTID组件

注释

UTID中的所有字母都应为小写。DNS也应写成小写。
每个组件的最大长度为64，但UTID的最大长度为96（包括分隔符）。
Dns及其分隔符（#）是必需的，因此最简单的UTID是“#sample.test”。
DNS至少应包含一个点（.）。不允许使用不带点的DNS。例如，localhost不是DNS，不能在UTID中使用。

3.2.2 完整UTID

UTID由四部分组成，其中三部分是可选的。为了提高可读性，如果省略了某一部分，则省略相对的分隔符。然而，这会在软件内部使用时产生混淆。解决方案是：在内部，如果省略了一个或多个部分，则使用完整格式的UTID。完整格式UTID是未省略任何分隔符的UTID，并以“!”开始，以标记UTID的开头。例如，123#sample.test的完整UTID是123$@#sample.test，它清楚地显示了哪个部分是空的。在这种情况下，目录和位置是空的。

3.2.3 UTID后缀

UTID后缀是UTID从一个字符到UTID末尾的子字符串。它用于匹配请求中的完整UTID以确定转发地址。UTID和UTID后缀都应为完整格式，因此本文中的所有UTID后缀均为完整UTID后缀。

例如，UTID后缀为“bc#sample.test”，其中“bc”是位置的最后一部分。另一个例子是“bc@#sample.test”，其中“bc”是目录的最后一部分，因为位置部分为空。

这样做的目的是确保在匹配UTID和UTID后缀时没有混淆。例如，“123$abc#sample.test”与“123@abc#sample.test”不同，但它们都可以匹配“bc#sample.test”的UTID后缀。这两个UTID在完整UTID中变为“123$abc@#sample.test”和“123$@abc#sample.test”。同时，UTID后缀应该是完整的UTID后缀，也就是说，它是“bc#sample.test”或“bc@#sample.test”。在这种情况下，可以避免混淆。

3.3 特性

唯一性：UTID是唯一的，因为它采用DNS来避免名称冲突。它从不依赖于任何上下文。
通用性：UTID并非为任何特定目的而设计，而是设计用于任何上下文，没有任何限制。
开放性：任何组织和个人都可以设计自己的UTID编码系统，而不会受到其他组织的任何限制。唯一的先决条件是设计者应拥有DNS名称。
路由：UTID支持两级路由，其中一级是DNS信息提供的IP路由，另一级是IDTP域内的IDTP追溯，由UTID后缀信息提供。
兼容性：UTID可以通过使用现有代码作为UTID的id部分来兼容现有的编码系统。对于电子邮件地址，我们可以使用符号~来代替符号@。

3.4 一些考虑

对于一个组织来说，设计UTID编码系统是一项复杂的工作，需要提前仔细设计。应该有一个用于组织拥有的事物以及有义务提供信息但并非组织拥有的事物事物的UTID全局架构。然后从dns、location、catalog和id四个方面设计UTID编码系统。

Dns：建议使用二级域名，如id、db或id1。例如：id.sample.test。
Location（位置）：位置的唯一考虑是满足IDTP的可追溯性要求。例如，一个dns代表一个包含一个或多个IDTP服务器的IDTP域。一个位置代表IDTP域中的一个IDTP服务器。因此，位置显示了IDTP服务器在IDTP域中的位置。另一个例子是，UTID“sensor@rm201.bld1#id.sample.test”代表了id.sample.test域中bld1楼rm201房间的一个小型嵌入式IDTP服务器。该服务器充当连接到房间内一些传感器的IDTP桥。
Catalog（目录）：不同的事物通常具有不同的属性。事物在不同状态下也可能具有不同的属性。同一目录中的不同事物可能共享一些共同的属性。目录反映了这些属性的差异，这些差异实际上是由请求和响应类表示的数据格式。因此，目录代表一个或多个Busilet、请求和响应的组（命名空间）。目录是事物和Busilet命名空间之间的一对多映射。
ID：根据组织的要求设计。或者使用现有的。

一个事物可能拥有由一个组织根据其位置或目录在不同状态或阶段分配的多个UTID。例如，一个温度传感器可能具有实时数据和历史数据。当我们访问实时数据时，我们需要直接连接到它。当我们访问历史数据时，我们需要连接到数据库。因此，UTID可能是“s0001$sensor.rt@rm201.bld1#id.sample.test”用于实时数据，而“s0001$sensor.db#id.sample.test”用于历史数据。

一个事物可能拥有由不同组织分配的多个UTID。例如，公司“sample1.test”生产了产品A，并为其分配了UTID“a.2013$p#sample1.test”。当产品销售给销售公司“sample2.test”时，同一产品可能被分配UTID“01$goods#sample2.test”。当产品到达一家将其用作固定资产的公司“sample3.test”时，同一产品可能被分配UTID“001.2013$asset#bld1#sample3.test”。这三家公司都应该提供关于该产品的信息，但方面不同。如果公司“sample1.test”拥有所有这些UTID，那么该公司应该能够追溯关于该产品的*所有*消息。公司“sample2.test”和“sample3.test”也可以交换UTID并保持联系。这样，就不会出现“信息孤岛”。

在上述示例中，公司“sample1.test”提供产品信息。公司“sample2.test”提供销售信息，公司“sample3.test”提供产品使用信息。但是，它们都应该就数据格式达成一致，即在不同上下文中的标准请求、响应和Busilet。

这只是一个例子。不同的设计者可能有不同的考虑。另一个例子是数据库应用程序，位置可能代表数据库，目录可能代表表，id可能代表记录的主键。

UTID的主要缺点是它是基于字符的，并且有点太长。因此，它不能用于长度受限的上下文或基于数字的编码上下文，例如一维条形码。

3.5 UTID的应用

UTID可能用于许多领域：

物联网应用
云计算
数据库管理
本地和远程过程调用
等等...

4 IDTP协议

UTID的所有者应该设置一个或多个IDTP服务器，它们构成一个IDTP域，为所有拥有的UTID提供信息。因此，任何用户都可以从IDTP客户端访问此信息。

IDTP协议实际上是一种远程过程调用（RPC），其中IDTP服务器是RPC的服务器，IDTP客户端是RPC的调用者。客户端发送一个带有名为request的参数的调用，并获得返回的数据称为response。因此，它是一个请求-响应模型。

4.1 设计原则

通用性：应支持各种底层协议，如TCP、UDP、UDP多播、Web服务和HTTP，或未来其他协议，如蓝牙、ZigBee，以扩展其应用范围。
可访问性：应能够到达任何地方，包括未直接连接到网络的传感器。
可追溯性：应能够通过UTID在IDTP域中将请求追溯到其目标IDTP服务器。
一致性：应能够使用统一的机制发送请求，无论本地调用还是远程调用，无论不同的底层协议。
简洁性：应足够简单，方便开发人员使用，足够简单，可以在任何类型的设备上运行，即使是计算能力较弱的设备。
兼容性：应与当前技术（如Web服务）兼容。

4.2 IDTP

4.2.1 特性

支持五种底层协议：TCP、UDP、UDP多播、Web服务和HTTP。
支持加密和认证。
支持会话。
不支持：压缩、连接、缓存。
默认：字符集为UTF-8，数据格式：JSON，以及SOAP（仅与Web服务通信时）。

4.2.2 数据格式

IDTP协议采用请求-响应模型，数据包含两个部分：头部和用户数据。

4.2.2.1 IDTP头部

IDTP协议的头部有两种类型：请求头部和响应头部。头部字段列在表2中。

名称	描述（示例）	请求	响应	备注
idtp	Idtp版本：busilet版本（0.9:1）	是	是
utid	客户端请求的UTID（aa#bb.cc）	是
ns	Busilet的命名空间（包）（utid.com.test.box）	是
名称	Busilet的名称（Register）	是
code	响应状态码（200）		是
len	数据长度（1234）	是	是
hop	跳数，最多为8（5）	是	是
hops 检查循环的跳数列表（aa#bb.cc\|bb#bb.cc）	是	是	除UDP外
enc	加密参数（rsa）	是	是	仅TCP

表 2. IDTP头部的字段

头部中的所有字段应在一行中，并严格按照表格顺序排列。所有字段名称都很短，以提高效率。每个字段都是一个键值对，用冒号“:”分隔，字段之间用分号“;”分隔。键和值没有引号，因此值中不允许包含冒号或分号。

4.2.2.2 UDP头部

当使用UDP作为底层协议时，数据长度有限制。为了在一个UDP数据报中包含更多用户数据，头部部分应尽可能短。因此，UDP的头部没有hops和enc字段，导致丢失以下功能：

轨迹追踪：Hops字段用于记录请求或响应经过的节点名称。它会动态增加，并可能导致用户数据丢失。幸运的是，hop字段可用于避免循环跟踪。
加密：Enc字段用于加密，这将增加用户数据的长度。

4.2.2.3 用户数据

用户数据采用JSON格式。未来可能支持其他格式，例如XML。

以下是一个示例。这是请求：

idtp:0.9:1;utid:101@db#sample.test;ns:utid.test.sample;name:Product;len:34;hop:1;hops:n0.demo.test
{"_attri_":"{}","sender":"Bella."}

这是响应：

idtp:0.9:1;code:200 OK;len:67;hop:1;hops:n1.sample.test
{"_attri_":"{}","name":"Pen","price":12.0,"remark":"Hello, Bella."}

4.2.2.4 为什么选择JSON

JSON的优点

JSON简单且使用广泛。
JSON可用于表达任何类型的数据。
JSON格式在数据长度上比XML格式短，从而节省网络流量。
JSON比XML更高效，并且易于在计算能力较弱的设备上处理。
JSON可直接被Ajax使用，无需任何转换。

JSON的缺点

JSON包含的元信息较少，特别是类型、属性信息。
与Web服务通信时需要格式转换。

4.2.3 数据类型

对于IDTP协议本身，用户数据可以是任何类型的数据。但是，我们需要做一些限制，以确保通信双方都能相互理解。

数据类型分为两组：基本数据类型和复合数据类型。

4.2.3.1 基本数据类型

IDTP协议支持以下六种基本数据类型：

Integer（整数）：32位整数。
Long integer（长整数）：64位整数。
Double number（双精度数）：64位双精度数。
Boolean（布尔值）：仅true和false。
String（字符串）：最大长度为64K的字符串。如果底层协议是UDP，数据长度有更严格的限制：整个请求或响应（包括头部数据）不得超过UDP数据报的最大长度。
Date（日期）：ISO-8601格式的字符串，也兼容Web服务。


不建议使用char、byte、short或float类型，因为它们在某些情况下可能导致溢出。如果需要使用其他数据类型，如超长整数、精度浮点数，可以将其转换为string并在客户端和服务器之间协商。

4.2.3.2 复合数据类型

IDTP支持两种类型的复合数据类型：用户定义类和一维数组。

用户定义类
- 它是一个普通的Java类，具有上述六种基本数据类型或另一个类的属性。
一维数组
- 基本数据类型（日期类型除外）或用户定义类的一维数组。
- 在Java中，数组、列表和集合转换为JSON时是相同的。IDTP不保证数据的顺序。

4.2.3.3 命名规则

非数组（基本数据类型和类）
- 采用低驼峰命名法，除非下述情况。
数组（Array、List和Set）
如果您不需要与Web服务兼容，也可以使用低驼峰命名法。

如果您需要与Web服务兼容，则必须遵守以下规则，因为XML包含数据类型信息而JSON不包含。结果是IDTP中的名称应包含数据类型信息。
- 采用匈牙利命名法。以下是两种情况：
  - 基本数据类型：前缀aoi、aol、aod、aob和aos分别代表int、long、double、boolean和string的数组。它可以跟任何以大写字母开头的字符。例如：aoiAge、aosStudenName。但是，aoiage不是数组的名称。没有日期类型的数组，因此日期类型应封装在类中，然后使用类的数组。
  - 用户定义的类：用户定义类数组的名称更严格。（1）前缀必须是“ary”；（2）其余部分必须是类的名称。因此，Student类数组的名称应为aryStudent。如果同一类有多个数组，则需要创建几个该类的子类，并使用子类名称来命名数组。
- 一些考虑
  - 类名的首字母应大写，属性和方法名的首字母应小写。这是Java语言的约定。
  - 非数组属性（基本数据类型和类）不能以ary、aoi、aol、aod、aob和aos开头，后面跟首字母大写的字符串，但可以跟首字母小写的字符串。因此，aryBook是Book类的数组，aoiDay是整数数组，但arybook和aoiday都不是数组。
- 内部属性
  有三个内部使用的属性。它们是_attri_、_session_id_和_utid_suffix_。开发人员不应在代码中使用这三个属性。

4.2.4 请求

Busilet4j API中的IdtpRequest类封装了请求头部数据和一些方法。

IDTP服务器和客户端的开发人员需要继承IdtpRequest类，并封装用户的请求参数。不应在其中放置任何方法。

4.2.5 响应

Busilet4j API中的IdtpResponse类封装了响应头部数据和一些方法。

IDTP服务器和客户端的开发人员需要继承IdtpResponse类，并封装用户的响应参数。不应在其中放置任何方法。

4.2.6 Busilet

每个busilet都有一个名称和一个命名空间（在Java中即包名），这些都包含在请求头部数据中。

Busilet在服务器端封装了业务逻辑，它处理来自客户端的请求，并将结果作为响应对象返回给客户端。因此，每个busilet都应实现BusiletExecutable接口中声明的方法：

IdtpResponse doBusiness(IdtpRequest idtpRequest) throws UtidException;

Busilet中不应有任何客户端业务逻辑。

4.2.6.1 Busilet

命名
采用大驼峰命名法。
业务逻辑
每个busilet应包含busilet逻辑的实现。它接收一个请求，执行busilet逻辑，然后返回一个响应。

每个busilet都有一对匹配的请求和响应。例如，一个名为“Demo”的busilet应有三个类，名称分别为：

DemoRequest：它封装了所有请求参数。

DemoResponse：它封装了所有响应结果。

DemoBusilet：它实现了doBusiness()方法，该方法封装了业务逻辑。

4.2.6.2 命名空间

命名空间用于对Busilet进行分组，并避免Busilet的名称冲突。它与Java语言中的包、C#语言中的namespace以及Web服务中的namespace完全相同，只是顺序相反。一个命名空间可以包含多个Busilet，就像一个包可以包含多个类，一个Web服务可以包含多个方法一样。

建议命名空间使用定义Busilet的DNS，并在前面加上“utid.”以表示该命名空间是IDTP的命名空间。例如，一个命名空间“utid.test.sample.sensor”代表由“smple.test”组织定义的Busilet组，并且Busilet与传感器信息有关。然而，在Web服务中，命名空间将变为“sensor.sample.test.utid”。

还建议在命名空间前加上“utid.pub.”，以表示Busilet是行业标准化的Busilet。例如：“utid.pub.test.sample.sensor”。

4.2.6.3 命名空间和目录

Busilet及相关的请求、响应是在通信双方之间协商的。它可能是企业标准或行业标准。因此，命名空间也是一个标准。

目录用于通过Busilet对UTID进行分组，这使得一组具有相同属性的Busilet拥有相同的名称，并使用同一组Busilet来访问UTID。由于UTID的多样性，目录名称是不规则的，并且是任意命名的，但命名空间应该是标准化的。

建立命名空间和目录之间的映射非常重要，这样开发人员就能从任意目录名称获得标准命名空间。这在Busilet4j项目中通过MapCatalogBusilet和catalog_map.xml文件完成。

4.2.6.4 内置Busilet

Busilet4j项目在“org.utid.busilet”命名空间提供了六个内置Busilet：

Infor：它通常用于提供IDTP域的通用信息。当省略命名空间和名称时，它是默认的Busilet。对于只需要处理一个Busilet的小型智能设备来说，它是最好的选择。您可以通过在配置文件中设置<default_busilet_class>将此Busilet重定向到另一个类。
MapCatalog：它用于提供目录和命名空间的映射信息。目录和命名空间之间的关系是多对多的。在Busilet4j项目中，映射数据存储在catalog_map.xml文件中。
Ping：它是一个用于测试的Busilet，就像TCP/IP中的ping命令一样。
PullFile：它用于从默认目录或配置的目录下载文件。
PushFile：它用于将文件上传到默认目录。
WSDL：它将获取IDTP服务器或Web服务服务器的WSDL，以便IDTP能够与Web服务兼容。

4.2.7 底层协议

IDTP协议是一个应用层协议，它依赖于底层协议的数据传输，底层协议可以是TCP、UDP、UDP多播、Web服务和HTTP之一。每个节点都可以根据要求（效率、所需功能、兼容性）选择底层协议，这扩展了IDTP协议的应用范围。

这五种协议如下：

TCP：这是最常见的。如果可能，应优先考虑它。
UDP：它是一种无连接协议，效率高，但对单个数据报的长度有限制。
UDP多播：它用于将请求多播到一组节点。它也对单个数据报的长度有限制。例如，用于查找哪些节点处于活动状态。在这种情况下，每个节点可能需要主动发送一个请求到多播发布者，在随机延迟一段时间后通过TCP协议告知它。
HTTP：它用于浏览器通过Ajax技术访问IDTP服务器。
Web Service：它用于与Web服务兼容以进行通信。

底层协议可以扩展，包括有线通信和无线通信。

4.2.7.1 TCP

优点是稳定可靠，适合传输大量数据或支持加密传输。缺点是由于三次握手，开销较大，不适合实时场景。

TCP、HTTP和Web服务可以共享同一个端口号，该端口号也用于WSDL发现。

4.2.7.2 UDP

优点是速度快、开销小，适合实时传输。缺点是可靠性低，单个数据报传输的数据量有限。

IDTP不使用UDP协议通过多个数据报发送请求或返回响应。每个请求和响应都应限制在一个数据报内。

4.2.7.3 UDP多播

优点是可以向IDTP域内的所有节点广播，例如发布通知或查询活动节点的名称。缺点是它只支持单向传输。但是，您可以要求接收节点在随机延迟后向多播发布者发送新的基于TCP的请求。

IDTP不使用UDP协议通过多个数据报发送请求或返回响应。每个请求和响应都应限制在一个数据报内。

UDP多播传输仅限于局域网，不能通过IDTP服务器进行追溯。但是，您可以使用基于UDP的请求通过IDTP服务器进行追溯，并在最后停止时进行多播。

4.2.7.4 Web Service

IDTP中的ns与Web服务中的命名空间完全相同，只是顺序相反。一个Web服务有一个命名空间和多个方法。IDTP中的一个ns包含多个Busilet。因此，Web服务中的一个方法相当于IDTP中的一个Busilet。Web服务中的方法名称就是IDTP中Busilet的名称。

为了使IDTP与Web服务兼容，Web服务也需要做出一些妥协。与IDTP兼容的方法应有两个参数：一个是要UTID字符串，另一个是封装所有参数的请求。与IDTP兼容的方法也返回一个响应对象，就像在IDTP中所做的一样。

配置Web服务时，需要将Web服务的URL添加到配置中。

4.2.7.5 HTTP

如果您采用HTTP作为底层协议，有两种实现方式：

与IDTP集成：IDTP服务器可以使用其TCP端口模拟HTTP服务并提供基于HTTP的IDTP服务。但由于跨域问题，这不适合Ajax访问。
集成Web服务器：在这种情况下，您可以在URI中声明一个路径来提供IDTP服务。所有到该URI的HTTP请求都将被视为IDTP请求。优点是IDTP进程与Web服务器进程共享，提高了效率。

通常，集成HTTP的IDTP是追溯路由的最后一步。在这种情况下，请求将不再转发（追溯）。

基于HTTP的IDTP协议的最大优势在于它允许任何浏览器通过Ajax技术访问IDTP服务器。

此外，IDTP服务器可以嵌入到Web服务器中以提供IDTP服务，但使用另一个独立的端口号。在这种情况下，底层协议仍然是TCP或UDP，而不是HTTP。以下是一些代码，展示了如何在Tomcat服务器中执行此操作：

public class InitSessionFactoryServlet extends HttpServlet {
	public InitSessionFactoryServlet() throws UtidException {
		
		System.out.println("Creating SessionFactory...");
		new Configuration().configure().buildSessionFactory();
		System.out.println("SessionFactory created.");

		String dns = "id.wxit.org";
		IdtpConfig.debugMode = true;
		IdtpConfig.domainName= dns;

		IdtpConfig.nodeName = "n1." + dns;
		IdtpConfig.addTracingTrack(dns);

		try {
			IdtpServer.startTcpServer(); //25604;
		} catch (UtidException e) {
			e.printStackTrace();
		}
	}

	@Override
	public void init(ServletConfig config) throws ServletException {
		ServletContext application = config.getServletContext();
		String imgPath = application.getRealPath("/") + "img/";
		PullFileBusilet.setPullFileRootPath(imgPath);
		PushFileBusilet.setPushFileRootPath(imgPath);
		System.out.println("Upload to: "+ imgPath);
	}
}

IDTP服务器在Tomcat服务器启动时使用IDTP端口号启动，而Tomcat服务器使用HTTP端口号。

4.2.8 关于Google App Engine

Java语言是Google App Engine中的一种编程语言。IDTP协议可以在Google App Engine上实现，并通过HTTP协议提供IDTP服务。

4.2.9 IDTP发现

IDTP与Web服务的WSDL兼容，因此IDTP可以使用Web服务的UDDI发现。它为IDTP提供了广阔的开发空间。

4.3 IDTP服务器和客户端

4.3.1 IDTP服务器

IDTP服务器的特性包括：

通过内置的Infor请求提供关于IDTP域的消息。
通过内置的MapCatalog请求提供目录映射的命名空间列表。
通过内置的Wsdl请求提供命名空间WSDL消息。
最重要且最后的任务是，在收到请求时，它会在Busilet中运行业务逻辑。

IDTP服务器的核心是Busilet，它提供RPC服务。每个IDTP服务器应为每个UTID目录拥有一或多个Busilet。

在面向对象的编程语言（如Java）中，Busilet是一个具有以下基本结构的类：

public class ProductBusilet implements BusiletExecutable {

	@Override
	public IdtpResponse doBusiness(IdtpRequest idtpRequest)
			throws UtidException {
		// prepare the request object and a response object
		ProductRequest request = (ProductRequest) idtpRequest;
		ProductResponse response = new ProductResponse();

		// business logic

		return response;
	}
}

一个IDTP服务器可能拥有各种Busilet类，它们按命名空间（包）分组。Busilet、Request和Response应在同一命名空间（包）下，具有相同的名称，但后缀分别为Busilet、Request和Response。

此外，Request和Response类在IDTP服务器和IDTP客户端中应完全相同。IDTP客户端可以省略Busilet。

在Busilet4j项目中，启动DTP服务器很容易：

	// Start TCP/WS IDTP server then it will accept idtp requests.
	IdtpServer.startTcpServer();
	
	// Start UDP IDTP server then it will accept idtp requests.
	IdtpServer.startUdpServer();

配置文件是idtp.xml，启动时必须读取该文件。

4.3.2 IDTP客户端

IDTP客户端的特性包括：

如果客户端知道应该使用哪个请求与服务器通信，则直接发送请求。
如果不知道，客户端可以发送一个Infor请求来查找UTID所属IDTP域的通用消息。
如果不知道，客户端也可以发送一个MapCatalog请求来获取UTID的映射命名空间。
如果不知道，客户端还可以发送一个Wsdl请求来获取命名空间的所有请求和响应元数据。
最后，客户端应该知道应该使用哪个请求与服务器通信。

IDTP 客户端向 IDTP 服务器发送请求调用 Busilet，并处理响应。需要强调的是，请求中的 UTID 非常关键，因为它包含了追踪消息。没有 UTID 的追踪消息，IDTP 协议将无法工作。没有 UTID，IDTP 协议将毫无用处。

4.4 加密与认证

数据安全是数据通信中的一个重要问题，尤其是在许多节点转发的条件下。这里我们只讨论加密和认证。我们建议尽可能讨论更多安全问题。

4.4.1 设计原则

兼容性：采用通用的加密算法，可在不同平台使用。
安全性：采用强度高的加密算法，确保通信安全。
通用性：加密和认证需要较高的计算成本。IDTP 协议是一个通用且无处不在的协议，适用于计算能力较弱的设备。因此，安全解决方案也应能在这些设备上运行。

4.4.2 加密与认证技术

4.4.2.1 加密技术

我们建议了两种加密技术

XOR 加密：这是一种非常简单的加密技术，通过手动交换密码。适用于相对安全环境中的小型设备。
AES 加密：这是 128 位 AES 加密技术，通过公钥技术（RSA 算法）交换 AES 密钥。它是最常见的加密算法之一，适用于大多数应用。

您可以通过使用这两种加密方法来建立追踪路由，以满足各种需求。例如，一个小型智能设备通过 XOR 加密连接到 IDTP 服务器，然后 IDTP 通过 AES 加密连接到另一个 IDTP 服务器。

4.4.2.2 认证技术

加密技术可用作认证。但 XOR 和 AES 加密之间存在一些差异

XOR 加密可用于相互认证。成功解密加密数据即表示认证成功。这是双向认证。
AES 加密使用证书交换 AES 密钥。但这并非认证。它需要一种方法来验证对方的数字证书。因此，服务器和客户端都应拥有其证书，并且双方都应能够验证对方的证书。

4.4.3 XOR 加密

这是一种非常简单且不安全的加密技术。它仅用于相对安全环境中的计算能力较弱的小型设备。出于安全原因，不允许连续两次连接使用。

4.4.3.1 密码协商

要求客户端和服务器手动交换密码并将其保存在配置文件中。密码应为 32 到 64 字节的数组，然后转换为 base64 编码的字符串。出于安全原因，不允许使用常用密码。密码协商在邻居节点之间进行，因此只能加密邻居节点之间的数据。

Busilet4j 项目在 SecurityTool 类中提供了 createXorPassword() 方法来生成此类密码。

密码保存在服务器和客户端的配置文件中。

4.4.3.2 加密与解密

加密：首先计算待加密原始数据的 crc32 值。然后将加密的密文和 crc32 值发送给对方。

解密：首先使用保存的密码解密密文。然后计算解密后的明文的 crc32 值。只有 crc32 校验成功，解密才算成功。

crc32 算法与 zip 压缩算法中使用的算法相同。

4.4.3.3 客户端

在发送请求之前，客户端会查找保存的密码并加密数据。然后以以下格式发送请求

head fields;enc:xor,crc32,n1.sample.test
ciphertext

其中 enc 字段用于通知服务器加密算法、CRC32 值和发送者节点名称。各部分之间用逗号分隔，没有空格。

4.4.3.4 服务器

收到客户端的请求后，IDTP 服务器会从头部获取发送者节点名称，查找节点的保存密码并解密密文。

响应应使用相同的密码进行加密，并以以下格式返回

head fields;enc:xor,crc32
ciphertext

返回的数据中不需要节点名称。

4.4.4 AES 加密

AES 是一种安全的加密技术。我们使用数字证书和公钥技术（RSA）来协商 AES 密钥，以提高安全性。

您可以使用商业证书或内部证书。前者适用于 IDTP 域之间的通信，后者适用于 IDTP 域内的通信。AES 加密可用于端到端加密，从而大大提高安全性。

Busilet4j 项目在 CertificationTool 类中提供了一些方法来生成证书和签名证书。

4.4.4.1 密钥协商

服务器证书用于密钥协商和服务器认证。客户端证书仅用于客户端认证。因此，在 AES 加密中，客户端证书是可选的。

为了提高效率，我们使用一次请求-响应来完成整个密钥协商过程。密钥协商由客户端发起。

客户端发送一个密钥协商请求（EncRsaNegotiateRequest），其中包含目标命名空间、一个 128 位随机数和一个可选证书。
服务器可选地验证客户端证书，从请求中的随机数和服务器自身的随机数生成一个 AES 会话密钥，并生成一个会话密钥 ID。然后，服务器使用其私钥加密 AES 会话密钥。最后，服务器将服务器证书、会话密钥 ID、加密的 AES 会话密钥和匹配的 utidSuffix 发送回客户端。
客户端可选地验证服务器证书，使用服务器证书解密 AES 会话密钥。密钥协商完成，可选认证完成。

在 Busilet4j 项目中，密钥协商被封装在 EncRsaNegotiateBusilet 类中。可能的结果包括：

失败：原因可能包括：网络故障、服务器故障、配置故障、系统故障。
成功但无认证：密钥协商成功，但认证失败。原因可能包括：证书过期、客户端没有证书。
完全成功：密钥协商和认证都成功。

4.4.4.2 会话密钥的保存

成功密钥协商后，服务器和客户端都拥有会话密钥的副本，该密钥是动态协商的，因此不应将其保存到文件中。

服务器端：将会话 ID 和会话密钥保存在 EncRsaNegotiateBusilet 类中的静态 Map 属性中。
客户端：将 utidSuffix 和会话密钥与会话 ID 一起保存在 EncRsaNegotiateBusilet 类中的另一个静态 Map 属性中。

4.4.4.3 客户端

在客户端发送请求之前，它会通过请求中的 UTID 消息查找会话密钥，以找到匹配的 utidSuffix 并获取会话密钥和会话 ID。如果找不到，则表示客户端和服务器之间没有协商密钥，因此将启动新的密钥协商。

然后，客户端使用会话密钥加密请求数据，并以以下格式发送：

head fields;enc:rsa,session kek ID
ciphertext

其中 enc 字段用于通知服务器加密算法和会话密钥 ID。各部分之间用逗号分隔，没有空格。

在某些情况下，客户端可能拥有会话密钥，但该会话密钥在服务器端已失效。这发生在会话密钥超时或服务器重启时。在这种情况下，服务器将返回一个响应，告知客户端加密失败，并且客户端应启动新的密钥协商过程。

4.4.4.4 服务器

收到请求后，服务器将根据请求头中的会话密钥 ID 查找会话密钥。然后解密请求数据。

响应应使用相同的会话密钥进行加密，并以以下格式返回：

head fields;enc:rsa
ciphertext

返回的数据中不需要节点名称或会话密钥 ID。

4.4.5 加密与追踪

如果通信是两个邻居节点之间，则加密和认证很简单。但在追踪过程中，请求可能会经过许多节点。在追踪转发中，如果一个节点加密数据而另一个节点不加密数据，则会出现安全问题。为避免此类错误，IDTP 协议提供了以下追踪规则：

加密和解密仅针对数据部分，不对协议头部进行。
请求是否加密由创建 Busilet 的一方决定，在 Request 中设置。
如果请求被加密，则响应也必须被加密，并且使用相同的算法进行加密。
追踪节点无法决定请求是否被加密。如果追踪节点收到加密的请求，则必须以加密形式转发。同时，如果追踪节点收到非加密的请求，则必须以非加密形式转发。如果服务器收到非加密的请求但该请求应被加密，服务器将返回错误消息，而不会进一步转发。
追踪节点可以决定请求的加密算法（如果需要加密）。追踪节点可以直接转发，或者解密后再用另一种算法（切勿使用相同算法）加密后再转发。这取决于管理员配置的节点设置。

4.4.6 特性

请求在所有节点上要么全部加密，要么全部不加密。严禁在某些节点加密而在其他节点不加密。在这种情况下，转发将终止并返回错误消息。
加密算法不是由客户端和服务器协商的。它由管理员配置的节点决定。请求者和响应者都无法确定加密算法，也不知道使用了哪种算法。
安全性与加密强度完全由管理员配置的每个节点决定。
仅 TCP 通信支持加密。即使只有一个节点不支持 TCP，也无法建立加密链。

4.5 可追溯性

可追踪性是 IDTP 协议的核心概念，因此我们可以说，如果没有可追踪机制，UTID 和 IDTP 将失去存在的价值。

追踪有两个级别

IP 路由：这是通过 TCP/IP 网络中的消息（UTID）将请求转发到 IDTP 域的过程。
IDTP 追踪：这是通过 UTID 中的消息将请求转发到 IDTP 域内的目标 IDTP 服务器的过程，该网络不仅包括 TCP/IP（例如 ZigBee）。

IDTP 追踪是一个全新的概念，即请求在 IDTP 域内转发，而不管 IDTP 域是位于局域网内还是跨越广域网。典型的 IDTP 域是 UTID 所有者的局域网。但是，它可以扩展到广域网，例如所有者拥有的远程主机，也可以深入到非 TCP/IP 网络，例如通过蓝牙或 ZigBee 连接到追踪桥接器的智能设备。

IDTP 追踪独立于 IP 地址或 DNS 名称。它仅依赖于 UTID 和 IDTP 节点的追踪配置。因此，IDTP 追踪的转发范围独立于 IP 子网或 DNS 架构。也就是说，IDTP 在 Internet 的基础上，为 IDTP 追踪在应用层建立了一个全新的独立网络。

本文不讨论 TCP/IP 路由。

IDTP 可追踪技术包括追踪网关（trace gate）和追踪桥接器（trace bridge）两种技术，它们有所不同，并在不同场景中使用。

4.5.1 追踪网关

追踪网关是一个 IDTP 服务器，它将请求追踪（转发）到 IDTP 域内的目标 IDTP 服务器。它可能会进行数据格式转换，或加密解密。

理论上，转发基于 UTID 的位置部分。但在实践中，转发不仅基于 UTID 的位置部分，还基于 UTID 的最后一部分，称为 UTID 后缀（UtidSuffix）。这带来了一些优点：（1）使 UTID 的设计更容易。有时，目录或 ID 的一部分可用作基础，省略位置部分，缩短 UTID 的长度。（2）使追踪规则更灵活。

作为 UTID 中的一个重要概念，位置引入了追踪的概念。在实现中，位置部分被弱化甚至可以省略，但它仍然是 UTID 和 IDTP 的核心概念。

4.5.1.1 追踪转发

追踪网关转发请求时有两个含义：

通过匹配请求中的 UtidSuffix 和 UTID 来查找下一个跳地址。然后将请求转发到该地址。
从管理员配置的配置文件中查找追踪参数（底层协议、端口号等）。然后使用这些参数将请求转发到该地址。

追踪网关在收到请求时可能有三种情况：

本地处理：如果下一个跳地址是本地的（用 # 标记），则为本地请求，将在同一服务器的同一进程中处理。
IDTP 追踪：如果找到了下一个跳地址但不是本地的。则转发到下一个跳。下一个跳可能在同一个 IDTP 域内，也可能在另一个 IDTP 域内。
IP 路由：如果未找到下一个跳地址。在这种情况下，请求将无条件地通过 TCP 协议（不加密）转发到请求中 UTID 的 DNS 的默认端口号（25604）。

4.5.1.2 追踪表

转发请求时应考虑两个因素：

下一个跳地址：即：去哪里？它由 UTID 和 UtidSuffix 的匹配确定。
追踪参数：即：如何去？它由请求中的命名空间确定。

因此，追踪网关使用追踪表来保存用于追踪请求的所有这些消息。追踪表由多个追踪项组成。每个追踪项包含两部分：

追踪路径
追踪参数

追踪路径
追踪路径用于保存下一个跳地址。有两种类型的追踪路径：

(1) 前向追踪路径：它包含三个部分：
- UtidSuffix：用于匹配目标 UTID。utidSuffix 可能
  1. 包含 UTID 的最后一部分；
  2. 仅包含 DNS 部分。在这种情况下，不能省略符号 #。
  3. 仅包含符号 #。这表示匹配任何 UTID，如通配符。
- nextHopAddress：下一个跳的地址（IP 地址或 DNS）。
- Tracing param：指向追踪参数的引用名称。见下文。
- 本地路径：它仅包含 UtidSuffix 。它没有下一个跳地址和追踪参数。但是，UtidSuffix 不能是“#”，这意味着所有 UTID 都被视为本地处理。
需要考虑的事项
- 匹配 UTID 和 UtidSuffix 时，两者都应采用完整格式。例如，UTID“123$sensor#sample.test”应转换为“!123$sensor@#sample.test”，而“123#sample.tes”应转换为“!123$@#sample.test”。UtidSuffix“sensor#sample.test”应根据匹配要求转换为“sensor@#sample.test”或“sensor$@#sample.test”，甚至“!sensor$@#sample.test”。这是为了避免匹配 UTID 和 UtidSuffix 时产生混淆。
- 下一个跳地址“127.0.0.1”不表示本地路径。它表示通过转发进程转发到同一台机器的另一个端口号。只有下一个跳地址为“#”才表示本地路径，并在服务器的同一进程中处理。
UTID 和 UtidSuffix 的匹配
- 将 UTID 和 UtidSuffix 都转换为完整格式，然后使用 String 类的 endsWith() 方法匹配 UTID 是否以 UtidSuffix 结尾。匹配顺序按 utidSuffix 的长度排序，最长匹配优先。
- 如果匹配失败，则匹配符号 #。它匹配任何 UTID。
- 如果再次失败，则通过 TCP 协议（不加密）转发到 DNS 的默认端口号（25604）。
追踪参数
追踪参数用于保存追踪的参数。追踪参数与命名空间相关联。一个命名空间最多有一个追踪参数，多个命名空间可以共享同一个追踪参数。追踪参数包含两部分：
- Namespace：表示追踪参数的命名空间。星号（*）匹配任何命名空间。
- Protocol parameters：有五种底层协议。每种协议都有不同的参数：
  - TCP：端口号。
  - TCP（带 XOR 加密）：端口号和密码的引用名称。
  - TCP（带 AES 加密）：端口号和证书的引用名称。
  - UDP：端口号。
  - UD：端口号和组播地址。
  - HTTP：端口号和路径。
  - Web Service：端口号和路径。
注意：如果 utidSuffix 是符号“#”，则协议参数不能带有加密选项，因为这意味着向任何其他 IDTP 服务器发送加密请求。如果您设置了加密选项，请确保 IDTP 服务器能够处理加密请求。
追踪表的配置
在 Busilet4j 项目中有两种配置追踪表的方法：
- 硬编码在程序中：使用 IdtpConfig 类中的方法在程序中配置所有内容。这很简单，仅推荐用于测试。
- 配置文件：配置文件是 Busilet4j 项目中的 idtp.xml。IdtpConfig 类中的 readConfig() 用于读取配置文件。它更灵活，推荐用于所有用途。

4.5.1.3 加密算法的更改

加密算法的更改仅发生在基于 TCP 的通信中。更改应为 XOR 到 AES 或 AES 到 XOR。绝不会在 XOR 和 XOR 或 AES 和 AES 之间发生更改。

在非 TCP 通信中发生加密更改时应返回错误消息。

4.5.1.4 数据格式的转换

当底层协议改变时，请求可能需要进行转换。

加密请求无法转换，因为只有 TCP 支持加密。如果发生这种情况，转发将终止并应返回错误消息。
当转换为基于 UDP 的通信时，如果数据长度超过 UDP 数据报的限制，转发将终止并应返回错误消息。

4.5.1.5 避免循环追踪

由于各个节点的配置一致性，可能会发生循环追踪。IDTP 协议使用跳数来避免循环追踪。如果跳数达到最大值（默认为 8），转发将终止并应返回错误消息。在基于 TCP 的通信中，还有一个头部字段 hops 用于记录追踪节点名称，可用于调试。

4.5.1.6 追踪冲突

由于各个节点的配置一致性，可能会发生追踪冲突。在这种情况下，同一个 UTID 可能从不同的客户端追踪到不同的服务器，导致不同的结果。

IDTP 不提供任何解决方案来避免这种情况。因此，管理员在设计 IDTP 域中每个节点的配置时应谨慎。

4.5.1.7 特性

关于 IDTP 追踪，程序员和管理员有明确的责任。程序员只负责发送请求和接收请求。他们不必或不能关心追踪过程。

客户端的程序员在发送请求时不知道请求是如何转发的。他们只关心 UTID 的值，该值决定了请求的转发位置。他们无需关心加密、认证和转发参数。
服务器的程序员不知道请求来自何处以及请求是如何转发的。他们只知道请求是本地的还是远程的，而没有任何关于加密、认证和转发参数的信息。

管理员负责通过编辑配置文件 idtp.xml 来配置每个节点。

请求的转发仅由配置决定，包括加密、认证和转发参数。
客户端必须是一个追踪网关，这样客户端就可以处理本地或远程请求。

4.5.2 追踪桥接器

追踪桥接器是放置在 IDTP 域和非 IDTP 设备边界处的 IDTP 服务器。追踪桥接器充当 IDTP 域和非 IDTP 设备之间的桥梁，并提供它们之间的数据通信，包括数据收集、数据转换和 UTID 映射。

追踪桥接器通过非 TCP/IP 网络（如 WSN、串行端口和工业总线）与非 IDTP 设备（如 RFID 阅读器、条形码扫描仪）进行通信。

追踪桥接器应负责维护 UTID 和设备编号的映射，以便每个设备都有一个 UTID 标识符。

追踪桥接器的功能如下：

数据收集：收到请求后，收集 UTID 指示的设备的数据，并将数据返回。
操作执行：收到请求后，向 UTID 指示的设备发送操作命令，并返回操作状态。
数据上报：定期收集设备数据并发送到 IDTP 服务器。

这些是定制功能，根据设备要求实现。

4.6 会话

会话是 IDTP 协议的内置功能。IDTP 会话类似于 HTTP 会话。

5 IDTP的实现

Busilet4j 项目是 IDTP 协议的参考实现。IDTP 协议的设计和修订以及 Busilet4j 的实现是同时进行的。自 2011 年 Busilet 项目启动以来，以及 2012 年 6 月 Busilet 项目在 sourceforge.net 的首次发布，IDTP 和 UTID 经历了无数次重新设计、重构和修订。同时，Busilet 也经历了无数次重新设计、重构和修改。由于这些原因，我没有在 sourceforge.net 上发布 Busilet 的新版本。

现在，我很高兴在 sourceforge.net 和 code.google.com 上发布新版本，届时 IDTP 和 UTID 将变得成熟，尽管 busilet 仍需改进。

Busilet4j 项目使用 Java 语言编写。但是，它包含一些特殊的代码，旨在自动转换为 C#。我希望 Busilet4j 项目能够自动转换为 C# 项目，并保持 Java 和 C# 代码的同步。

5.1 系统设计

系统设计基于前面讨论的 IDTP 和 UTID。

5.2 包结构

项目中包含五个包：

org.utid：仅包含 Utid 类和 UtidException 类。

org.utid.busilet：包含声明 Busilet 类、Request 类和 Response 类的类。还有六个内置 busilet。

org.utid.idtp：这是 IDTP 的核心。它实现了五种底层协议、追踪、密钥协商、加密解密、会话。还有一个负责 IDTP 配置的 IdtpConfig 类。

org.utid.javacsharp：这用于 C# 语言。此包中的类封装了 Java 和 C# 之间的差异。

org.utid.tool：它为开发人员提供了四种工具。BusiletTool 类用于生成 Busilet、Request 和 Response。CertificationTool 类用于生成数字证书并签名证书。CsharpTool 类用于将源代码转换为 C# 代码，但目前工作不正常。DatabaseTool 类用于从 hibernate 数据库模型生成一些 DAO、Busilet、Request 和 Response。

5.3 详细设计

这里只讨论两个关键问题。

5.3.1 会话

会话是端到端的。所有与会话相关的代码都在 IdtpSession 类和 BusiletDispatcher 类中。

会话独立于转发。转发应确保保持 sessionId 的值。会话存在于 TCP 和 UDP 通信中，存在于本地调用和远程调用中。本地调用和远程调用的统一接口允许程序员更轻松地编写本地调用和远程调用程序。

5.3.2 转发与加密

本地到本地：无加密。由 BusiletDispatcher 类处理。
远程到本地：先解密请求，本地处理后，加密响应并返回。由 TraceGate 类中的 acceptRequestByTcp() 方法处理。
远程（或本地）到远程：分为三个阶段：
- 转发前：如果请求是 XOR 加密的，则解密请求，然后用 AES 算法加密。如果请求是 AES 加密的，则仅当下一个跳不是 XOR 时才转发，或者解密并用 XOR 算法加密。
- 转发：不进行任何特殊处理地转发请求。
- 转发后：即响应的处理。这与之前的操作完全相反。

5.4 未实现的特性

Busilet4j 中有些功能尚未实现：

服务器和客户端证书的认证。
兼容 Web Service：在早期版本中可用。但在一轮大改版后可能无法工作。
基于 HTTP：在早期版本中可以在 tomcat 服务器上工作。但在一轮大改版后可能无法工作。在 ASP 或 PHP 中实现将很困难。
从 IDTP 服务器生成 WSDL 文件。
自动转换为 C# 项目。
过滤器。

5.5 JUnit测试

Busilet4j 项目提供了一些 JUnit 测试。以下是简单到复杂的列表：

test.org.utid：测试 utid、request 和 response。
test.org.utid.simple：这是最简单的。
test.org.utid.session：这与上面类似，但增加了会话功能。
test.org.utid.encrytipn.xor：这是 XOR 加密测试。加密仅适用于 TCP。因此，本地和 UDP 通信不加密。
test.org.utid.encrytipn.rsa：这是 RSA-AES 加密测试。仅提供 TCP。
test.org.utid.trace：这是用于追踪测试。先运行所有四个服务器，然后运行 TestTcpCall。
test.org.utid.trace.encryption：这是用于带有 XOR 和 RSA-AES 加密的追踪测试。先运行所有四个服务器，然后运行 TestTcpCall。

在包 test.sample 和 utid.test.sample 中有一个教程示例。

5.6 用法说明

目前没有用户手册，这已在我三个月的计划中。这里讨论两个关键问题。

5.6.1 UTID 的设计

IDTP 域中 UTID 的设计非常重要。本文第 3.4 节已对此进行了详细讨论。

5.6.2 追踪规则

IDTP 有两个级别的路由。其中重要的是追踪规则。示例如下：

<?xml version="1.0" encoding="UTF-8"?>
<idtp xmlns="http://www.idtp.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.idtp.org idtp.xsd">
	<this_node>
		<!-- used when receive a request as server side -->
		<domain_name>id.test.com</domain_name>
		<node_name>n0.test.com</node_name>
		<debug_mode>false</debug_mode>
		<default_busilet_class></default_busilet_class>
		<multicast_address>224.5.6.7</multicast_address>
		<multicast_port>25605</multicast_port>
		<certification_folder>D:\ProgramSpace\java1\busilet4j\cert\</certification_folder>
		<certification_server>server_utid_org~root_utid_org.cer</certification_server>
		<certification_private_key>server_utid_org.keyr</certification_private_key>
		<certification_password>server.utid.org</certification_password>

		<!-- used when send a request as client side -->
		<node_xor_password name="mypassword"
			password="625oMgacMxFITa9MI9SuC6l/toVWarGJX1sGCWX5FFrpSWv3GOtf9RfQQ/Si" />
		<node_certification name="mycert"
			certification="client_utid_org~root_utid_org.cer" private_key="client_utid_org.key"
			private_password="client.utid.org" />
	</this_node>

	<neighbor_node>
		<!-- used when receive a request as sever side -->
		<xor_password node_name="n0.test.com"
			password="625oMgacMxFITa9MI9SuC6l/toVWarGJX1sGCWX5FFrpSWv3GOtf9RfQQ/Si" />
		<xor_password node_name="n2.test.com"
			password="uvl2xVTOGYvOP6iDS3+oxc6I1ZzpCM4KfHzpk83Qh5kdRASDsmHo4WyCfrqcImxkTuaZCBCz4/s4HnN5" />
	</neighbor_node>

	<tracing_parameters>
		<tracing_parameter name="myParam1">
			<!-- * match any namespace -->
			<namespace name="*">
				<!-- one of tcp/udp/umc/ws/http -->
				<tcp port="8081" />
			</namespace>
			<namespace name="aaa.com">
				<tcp-xor port="8081" ref_node_xor_password="mypassword" />
			</namespace>
			<namespace name="bbb.com">
				<tcp-rsa port="8081" ref_node_certification="mycert" />
			</namespace>
			<namespace name="ccc.com">
				<udp port="8081" />
			</namespace>
			<namespace name="ddd.com">
				<udp_multicast port="8082" multicast_address="224.3.2.1" />
			</namespace>
			<namespace name="eee.com">
				<http port="8083" path="/utid/idtp?HTTP" />
			</namespace>
			<namespace name="fff.com">
				<web_service port="8083" path="/utid/idtp?WS" />
			</namespace>
		</tracing_parameter>
		<tracing_parameter name="myParam2">
			<!-- * match any namespace -->
			<namespace name="*">
				<tcp port="8081" />
			</namespace>
		</tracing_parameter>
	</tracing_parameters>

	<tracing_tracks>
		<tracing_local full_utid_suffix="#test.com" />
		<!-- # match any utid -->
		<tracing_track full_utid_suffix="test0.com"
			forward_address="127.0.0.1" ref_tracing_parameter="myParam1" />
		<tracing_track full_utid_suffix="#test1.com"
			forward_address="127.0.0.1" ref_tracing_parameter="myParam1" />
		<tracing_track full_utid_suffix="@#test2.com"
			forward_address="127.0.0.1" ref_tracing_parameter="myParam1" />
		<tracing_track full_utid_suffix="#" forward_address="127.0.0.1"
			ref_tracing_parameter="myParam2" />
	</tracing_tracks>
</idtp>

6 IDTP的应用

IDTP 和 UTID 技术可广泛用于计算，包括：

程序技术：RPC、本地调用、Web Service。
研究：数据库管理、分布式计算、网格计算和云计算。
应用领域：物联网（IOT）、车联网（IOV）、供应链管理、产品追溯、食品追溯等。

6.1 本地调用与远程调用

它消除了本地调用到远程调用的边界。程序员可以以相同的方式调用本地或远程过程。这将影响计算的设计。

6.2 数据库技术

UTID 可用作数据库中的主键和外键。任何人都可以搜索追溯到其原始来源的外键信息。因此，这里的外键是一个传统的外键。它是一个分布式外键或追踪键。它将影响数据库技术概念和设计，尤其是在食品追溯、供应链管理中。

6.3 TCP/IP

IDTP 基于 TCP/IP 但不限于 TCP/IP。它建立了一个独立于 TCP/IP 的网络，具有独立的追踪网关和追踪桥接器转发机制。它可能用于物联网（IOT）、车联网（IOV）和移动互联网。

7 结论

这里是一个简单的 SWOT 分析：

优势：它开放、通用、灵活且可追踪。追踪是一个全新的概念和技术。
劣势：它是一个新来者，需要时间让人们认识和理解它。UTID 是基于字符的，IDTP 是基于 Json 的，因此有些人会因为各种原因不喜欢它。
机会：物联网的发展需要新的想法和概念来应对新的挑战。
威胁：针对不同用途（如行业、类别和用法）的 Busilet 标准化。如果没有 Busilet 的标准，ITDP 和 UTID 将毫无价值。因此，IDTP 开发的瓶颈在于 Busilet 的标准化。

简单成就世界。

治理复杂世界的原则很简单，即物理、化学或生物学原则。本文作者从小就有一个想法，希望用简单的原则来解释复杂的世界。

UTID 简单，IDTP 也简单。作者真心希望这些简单的积木能够构建一个复杂的计算世界。