IDTP, An Innovative Communication Protocol

Abstract

This paper discusses IDTP specification and UTID specification, which was designed by the author of this paper in recent three years. The UTID (Universally Traceable Identifier) is used to identify anything in the real world or virtual world. The IDTP (Identifier Tracing Protocol) is a communication protocol to access the information of a thing that identified by UTID.

This paper also introduced project Busilet4j, which is a reference implementation of IDTP that provides a set of APIs for Java developers to develop IDTP server and IDTP client software.

Contents

1 Introduction

1.1 Overview

1.2 Objectives

1.3 Readers of this paper

1.4 Why a new protocol?

1.5 Terminology

1.6 Comparison to other technology

1.7 History

1.8 Summary

2 Tutor sample

2.1 Designing UTID

2.2 Design of IDTP Server

2.3 Design of IDTP Client

2.4 Running

3 UTID identifier

3.1 Design Principles

3.2 UTID

3.3 Features

3.4 Some considering

3.5 Application of UTID

4 IDTP protocol

4.1 Design Principles

4.2 IDTP

4.3 IDTP Server and Client

4.4 Encryption and authentication

4.5 Traceability

4.6 Session

5 The implementation of IDTP

5.1 System design

5.2 Package structure

5.3 Detail design

5.4 Features not implemented

5.5 JUnit test

5.6 Usage description

6 Application of IDTP

6.1 Local call and remote call

6.2 Database technology

6.3 TCP/IP

7 Conclusions

1 Introduction

This paper is an "all in one" design document, which includes design idea, system architecture, system design, detail design, implementation, usage description, and example applications.

1.1 Overview

The main purpose of this paper is to describe the design specification of Identifier Tracing Protocol (IDTP). The project Busilet4j is a reference implementation of IDTP and showed how the specifications were implemented. The Busilet4j provides some API for developers to write IDTP server and IDTP client program in Java language. Therefore, this paper may use the Busilet4j implementation to describe the details of the IDTP specification.

Note: The Busilet4j project will provide an implementation named Busilet4net using C# language, which supports developers to write IDTP server and IDTP client program in C# language. For the purpose, some Java codes in Busilet4j were written in a way that would be converted into C# codes more easy.

1.2 Objectives

The Internet of Things (IOT) may be understand as "A internet of thing to thing", which is a huge network of various communication technologies among all things in the world. In the point of IOT, a thing could be considered as the information provider (information of the thing, or data of the thing when the thing is a sensor) because a client could see the provider rather than the thing itself. A thing also could be considered as the executor of an action (when the thing connects to a relay to turn a lamp on or off). In this paper, a thing could be a thing in the real world, but also could be a thing in the virtual world.

Therefore, (1) everything should have a uniform identifier to identify anything in the real world or virtual world; (2) everything should have a universal communication channel to other thing to reach to anywhere in the real world or virtual world. The objectives of the IDTP is to provide a general solution to communicate among things in the world, that is, a method to identify things (UTID, Universally Traceable Identifier) and a protocol to exchange information of things (IDTP, Identifier Tracing Protocol).

In addition, the UTID and IDTP is so general and universal that they suggested a new data communication channel for computation architecture and could be applied in many other fields, such as database management, distributed computation, cloud computation.

1.3 Readers of this Paper

The readers are three groups:

• Academic researchers on IOT, Web Service, cloud computation, and ubiquitous computation
• Developers for maintenance Busilet4j, or for developing a new implementation of IDTP
• Developers for developing IDTP application software (server or client software) using Busilet4j APIs

1.4 Why a new protocol?

There are various coding systems and communication protocols widely used in the IOT. The EPC and Web Service are the typical ones that make a great contribution to the development of IOT. However, any technology inevitably has some disadvantages. For example, EPC is mainly used in identifying products in production process and shipping goods in logistics and is the best coding system in the context. But in the era of IOT, after being produced, a product will go through circulation process, storage process, and consumption process. The same product might need to be recorded in a different process by a different company using different coding system to provide and share the information of the same product in the different status from different company. For example, no company would like to identify its fixed assets using EPC system, which is originally designed for identify products. The problem is the communication among these different companies and different coding systems. The result is the producer is difficult to trace the outgoing process and the consumer is difficult to find the information in the circulation process except the producer. Another example is IP protocol, the key technology in the Internet. But it could not be applied to a network consists of sensors that do not have IP address.

In general, we need a coding system and a protocol that are more open, more generalized. This specification provides such an open solution that is independent to any industry or any context.

1.5 Terminology

UTID (Universally Traceable Identifier): It is a unique identifier to identify a thing.

IDTP (Identifier Tracing Protocol): It is communication protocol for exchange thing’s information. It is a protocol in application layer in the Open Systems Interconnection (OSI) model.

Busilet (little business): It is the business logic that provides information of a thing. It is named after applet and servlet.

Request: It is a (Java) class used to represent the request parameters when accessing information of a thing. It encapsulates the UTID of the thing to be accessed and all other request parameters.

Response: It is a (Java) class used to represent the information of the thing returned back to the requester. It encapsulates all concerned information of the thing.

Namespace: It is used to grouping Busilet and avoids the naming conflict of Busilet. It is exactly same as package in Java language and namespace in C# language. It is also same as namespace in Web Service but in reverse order.

IDTP Server: It is the node that provides information of a thing identified by UTID. After accepting a request, it will execute the business logic in a matched Busilet and then return a response with information of the thing identified by the UTID to the requester.

IDTP Client: It is the node that sends a request for information of a thing identified by UTID in the request. It expects to receive a response from an IDTP server and doesn’t concern about the business logic in the Busilet.

IDTP node: An IDTP node or node in this paper is an IDTP server or IDTP client. A node usually acts as a server and a client at most times.

Node name: Each node should have a name, which is global unique consisting of DNS name and a sub domain name. An example is "n1.sample.test".

Trace: It is the process of tracing the location of a thing identified by UTID and forwarding the request to the target IDTP server. The response will be returned back to the requester in the same routing. It is called trace to void confusing it with the widely used word "forward".

Trace gate: It is the node that is responsible for the trace (forward) of requests. It is an IDTP server that traces a request and optional conducts data format conversion. It is like a gateway in the Internet, but it works in IDTP protocol, which belongs to application layer. It could be considered as an IDTP gateway.

Trace bridge: When tracing a request to a thing that is located outside the boundary of the IDTP protocol, it is necessary to have a bridge to connect the thing and IDTP. Like a bridge in the Internet, a trace bridge is an IDTP node that connects to a non-IDTP node through any available communication channels such as ZigBee, Bluetooth, CAN, or serial port. The bridge also needs to negotiate with the non-IDTP node the communication method and exchange format.

IDTP domain: It is a group of IDTP nodes with same operation rules and policy, usually owned by same organization. Therefore, the owner could be able to make a unified rules and policy for tracing in the IDTP domain. The tracing in an IDTP domain is independent of IP address or DNS name and is different to the IP forward.

IDTP domain name: Each IDTP domain should have a name, which is the DNS name of the IDTP domain and shared by all nodes in the IDTP domain. An example is “id.sample.test”.

IDTP port number: IDTP has registered its port number 25604 in IANA in 2011. This port number is recommended as a default port number of IDTP.

Local processing: It means that the requester and the responder is in same process, that is, same port number.

Remote processing: It means that the requester and the responder is NOT in same process, that is, different machine or different port number in same machine.

1.6 Comparison to other technology

1.6.1 Comparison with Web Service

Web Service is one the communication protocol that similar to IDTP. Web Service is a standardized and matured protocol which is widely used in many fields. But IDTP and Web Service have some differences.

• Lightweight: IDTP is a lightweight protocol, which is not only suitable for RPC (remote procedure call) but also suitable for local call, where the cost is the creation of three classes (Request, Response, and Busilet) only. It allows program to concern the business logic without the concern of remote or local process. Otherwise, Web Service is not recommended to be used in local call.
• Ubiquitous: For the IDTP, the requirement for computing capacity of the equipment is low, so the application fields may be extended to embedded system and smart devices. While Web Service needs more computing capacity and limits its application.
• Encapsulation: For IDTP, all parameters are encapsulated into request and response objects only. But Web Service may have more than one request parameters, which increase the complex.
• Two level routing: There are two levels routing in the IDTP, of which one level is IP routing provided by TCP/IP, and the other level is IDTP trace in the IDTP domain that makes the IDTP protocol more flexible and convenient and is suitable for the use in IOT.
• Binding to UTID: IDTP must work together with UTID. IDTP will lose its value without the cooperation of UTID.
• Security: IDTP has a built-in encrypted communication using AES encryption algorithm and RSA public-key key exchange technology. In addition, IDTP also provide XOR encryption algorithm for the devices with weak computing capacity in a relative secure environment, such as a LAN in the IDTP domain.
• Session: IDTP also provides built-in session function, which is similar to HTTP session.
• Application scope: IDTP and Web Service are similar but their application scope is a little different. IDTP mainly applied in IOT.

On the other hand, IDTP is compatible with Web Service. IDTP adopts WSDL definition file to define IDTP Busilet and introduces the UDDI discovery mechanism. IDTP could communicate with Web Service, and vice versa. In addition, IDTP may use WSDL definition file from Web Service server to generate IDTP busilet, request, and response class and Web Service also may use WSDL definition file from IDTP server to generate Web Service server or client codes. In one words, IDTP and Web Service can complement each other and develop together.

For the compatible with Web Service, the design of IDTP may have some special consideration, for example, the parameter’s name is specially designed for the compatible with Web Service.

1.6.2 Comparison with EPC

The Electronic Product Code (EPC) is designed as a universal identifier that provides a unique identity for every physical object anywhere in the world. It is a major technical standard widely used in IOT. Just like EPC, UTID is also a universal identifier system with many similarities. Following are some differences between them:

• Open: UTID is open because it is built directly from DNS. Any organization and individual with DNS name may have their UTID system and use it without any more efforts. EPC is also open but needs to register and have ONS system to resolve EPC to DNS.
• Ubiquitous: UTID is designed to identify anything in the real world or virtual world with flexible and variable length code format. But EPC is designed to identity physical object and with strict code format.
• Two level routing: Both EPC and UTID have two level routing. However, they are different. The two levels routing of EPC both are TCP/IP routing with ONS in the middle. While the two levels routing of UTID consists of TCP/IP routing and IDTP tracing.
• Character-based: EPC is bit-based with fixed length. UTID is character-based with variable length. Therefore, UTID is a bias code system and the efficiency of UTID may be a little lower. But the advantages are flexible and readable. And the efficiency will become less concerned while the computation capacity increases rapidly.

Generally speaking, UTID and EPC are for different requirements and applied for different area. We do hope that UTID complementary with the EPC, IDTP complementary with the Web Service and all of them will become important technology in the IOT and develop rapidly.

1.7 History

The concept of IDTP and UTID was bringing forward in the April of 2011, inspired by the idea of things mail system from my friend. In 2011, I wrote two academic papers with my friend:

• 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

From May of 2011 until August of 2013, the architecture and design of IDTP and UTID had been experienced numerous modifications and the Busilet4j project also redesigned and revised again and again to reflect the changes of IDTP and UTID. I registered IDTP port number 25604 in IANA on 9^th. August, 2011. The Busilet4j project also published in sourceforge.net as open source software in June, 2012. The URI is http://sourceforge.net/projects/busilet/.

The Busilet4j API in various development stages has been applied in real projects in these two years. These four projects are as follows:

• Things mail system: This is the project that inspired the concept of IDTP and UTID. The project had been put in use and runs in Linux server and Android terminal. It achieved all designed objectives which had been published in the above two papers. Unfortunately, it has not been promoted successfully because of financial problems.
• Network locker project: This is an enterprise customized project that runs on Android terminal for two year.
• Crop fertilization project: This is also an enterprise customized project that runs on Windows.
• Crop seed tracing project: This is a complex project including seed package, wholesale, retail, and seed information tracing. It runs on Windows, Web Server, Android terminal in workshop when packaging seeds, and WinCE PDA in warehouse. IDTP is the communication protocol among these devices and UTID is used to identify the seed package and tracing the seed information.

As an associate professor in a college, I tutored three groups of students to attend national competitions using IDTP and UTID technology:

• 2012 National Vocational Students Skills Competition (IOT technology application category): My team won second award (ranked 5^th in the category). We designed the system by using IDTP and UTID technology.
• The 17^th International ICT Innovative Services Contest 2012 (Taiwan): My team won second award (ranked 3^rd in Asia Pacific Exchange Group). This is an improved version of the things mail system and showed all idea and design of IDTP and UTID.
• 2013 Fourth Android Application Development China University Challenge: This project adopts IDTP as a communication channel only and doesn’t show the idea and design of IDTP and UTID.

The Busilet4j project is published in https://code.google.com/p/busilet/ from October, 2013.

1.8 Summary

During the two and half years, the author of this paper has improved, redesigned, and revised IDTP and UTID numerous times and was not satisfied with the results. As the result, Busilet4j was not published new release on sourceforge.net. When the last key technique had been solved in September of 2013, the IDTP specification has been rewritten and the Busilet4j project has been redesigned, refactored, and recoded, mainly related to trace, encryption, and session.

Now, it’s my pleasure to announce that the project be published in a new face and make contributions to the open source software forum after nearly three years of efforts.

2 Tutor Sample

Let’s recognize IDTP and UTID from a tutor sample. A company "sample.test" would like to provide information query function for its products. The information is located in a place named "db". There are tow products, numbered 101 and 102, which will be queried by users.

The company builds an IDTP server to provide the information query. A client should send a query from an IDTP client to get the information of the products. Therefore, there are should be one IDTP server and one IDTP client project in our tutor sample.

2.1 Designing UTID

As the producer of the products, the company "sample.test" should assign unique identifiers to its products. The two products are assigned "101@db#sample.test" and "102@db#sample.test" in UTID form in this tutor.

2.2 Design of IDTP Server

We will use Eclipse to develop the project. There is should be a configuration file for log4j, such as log4j.properties in an IDTP project.

Create a new Java application project named "IdtpServer" and include busilet4j_0.95.jar and some dependent jar file to the project’s Java Build Path:

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

The first step is to create busilet, request, and response class. You may create them by hand or create them using a tool. Create a class in the project with the following code:

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");
	}
}

The createEmptyBusilet() method will create busilet, request, and response class for you. These classes will be in a package named "utid.test.sample", where utid is automatically added by the tool to indicate that this class is UTID class. These three classes are named ProductRequest, ProductResponse, and ProductBusilet, respectively. Now it’s time to make little changes to these three classes:

The first class is a request class named ProductRequest, which will look like this:

package utid.test.sample;

import org.utid.busilet.IdtpRequest;

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

A request class should extend IdtpRequest class.

The second class is a response class named ProductResponse, which encapsulates two properties: product name and price returned back to requester:

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
}

A response class should extend IdtpResponse class.

The third class is busilet class named ProductBusilet, which accepts a request and returns a response as the result to the requestor:

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;
	}
}

A busilet class should implement BusiletExecutable interface and implement doBusiness() method.

The last step is to setup an IDTP server by creating a class named Server with the following code:

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();
	}
}

The key in the code is IDTP server trace configuration, which indicates the server to accept any request with UTID that ended with "@db#sample.test". After the server starts running, it will monitor the IDTP default port number 25604 giving running information as follows:

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

Now the IDTP server is running and waiting for incoming requests.

2.3 Design of IDTP Client

Create another Java application project named IdtpClient, including all jars file as same as the server project. Don’t forget configuration file log4j.properties for log4j:

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

The first step is also to write the request and response class but without busilet class. We should copy these two classes from the server project to make sure they are exactly the same. The request and response class in server and client should be exactly the same, including package name, class name, properties name and data type. Otherwise it cannot be run properly. We don’t need busilet class in client side because a client doesn’t concern the business logic.

The second step is to create a client class named Client with the following code:

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());
		}
	}
}

The key in the code is also the trace configuration, which indicates that all request with UTID ended with "@db#sample.test" will be traced to 127.0.0.1 (this machine acts both as server and client) by using tracing parameter named "mytcp", which is defined as using TCP default port number 25604 and match any namespace (symbol star * means match any namespace).

The above code could be divided into three steps:

1. Prepare an instance of ProductRequest class and setup some parameters, especially the correct value of UTID.
2. Send the request by calling BusiletDispatcher.doBusilet() method.
3. Deal with the response.

2.4 Running

Run the client code when the server is still running and you will read the output form the console:

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.

It showed the query result. You may also read the server’s output from the console:

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

It is very simple just as a tutor sample, demonstrating the basic process to setup a communication between IDTP client and IDTP server. For more complex case, there should be more complex design about the UTID and trace configuration both in server and client side.

3 UTID Identifier

The IDTP is a protocol to access information of a thing, which should be identified by UTID. Therefore, let’s discuss UTID specification first.

The operation of IOT is based on the identification of things, which should have one or more identifiers. A thing might be in different stage, located in different place, owned by different company, considered as different status and might need different identifiers to identify these differences. Therefore, we need a universal, simple coding method to identify anything and make them communicate to anywhere.

3.1 Design Principles

• Unique: This is a basic principle. Each identifier uniquely identifies a thing in the real world or virtual world. But a thing may have one or more identifiers to identify the thing in different aspect.
• Traceable: The identifier should contain necessary message to trace its information. That is who owned it and where it is.
• Universal: The identifier should be able to be applied to anything. That means it should be simple, open, and compatible with current technology.

3.2 UTID

3.2.1 Definition

When we trace a thing in the IOT, we need to know what the thing is, who owned the thing, where the thing is, and how to handle the thing’s information. That is 3WH. The identifier (UTID) of a thing in IDTP protocol should have the following basic properties:

• Dns: It marks the owner of a thing. Every thing MUST have an owner, which is not legal owner but is the one who is able to provide information of the thing. If a thing doesn’t have a legal owner, the one who is responsible to provide information of the thing is the owner of the thing. The owner has two duties:
  1. Assign a UTID to the thing;
  2. Promise to provide information of the thing.
• Location: It indicates the place the thing located, which actual is the location of IDTP server that could provide information of the thing.
• Catalog: Everything in same catalog should have same type of information so that we may handle the information in the same way. Catalog reflects the data format of thing’s information, or data format standards. These data format standards may be company standard, industry standard, or international standard.
• Id: It is a unique name with or without meaning, such as serial number, UUID, user name, or primary key in a database.

Now, we define the format of UUID:

id$catalog@location#dns

An example of UTID is 101$sensor@room102#sample.test, which can be read as 101 of sensor at room102 in sample.test.

Component	Separator	Example	Available character	Max length	Optional
dns	#	sample.test	Dns specification (small letters only)	64	Required
location	@	room102	a-z_0-9.-	64	Optional
catalog	$	sensor	a-z_0-9.-	64	Optional
id		101	a-z_0-9.-~	64	Optional

Notes

• All letters in UTID should be in small case. The DNS should also be written in small case.
• Max length of each component is 64, but the max length of the UTID is 96 (including separator).
• Dns and its separator (#) is not optional, so a simplest UTID is like this "#sample.test".
• A dns should contain at least one dot (.). A dns without dot is not allowed. For example, localhost is not a dns and could not used in UTID.

3.2.2 Full UTID

A UTID consists of four parts, of which three parts are optional. To increase the readability, the relative separator is omitted if one part is omitted. However, this will result in confusion when used in software internal. The solution is that in the internal a full format UTID should be used when one or more parts are omitted. The full format UTID is a UTID that doesn’t omitted any separator and begin with "!" to mark the beginning of a UTID. For example, the full UTID of 123#sample.test is 123$@#sample.test, which clearly shows which part is blank. In this case, the catalog and location are blank.

3.2.3 UTID Suffix

UTID Suffix is a substring of a UTID from one character till the end of the UTID. It is used to match the full UTID in a request to determine the forward address. Both of the UTID and UTID Suffix should be in full format so that all UTID Suffix is full UTID Suffix in this paper.

For example, there is UTID Suffix "bc#sample.test" where "bc" is the last part of location. Another example is "bc@#sample.test where "bc" is the last part of catalog because the location part is blank.

The reason is to make sure there is no confusing when matching UTID and UTID Suffix. For example, "123$abc#sample.test" is different from "123@abc#sample.test" but both of them may match UTID Suffix of "bc#sample.test". The two UTID becomes "123$abc@#sample.test" and "123$@abc#sample.test" in full UTID. At the same time, the UTID Suffix should be a full UTID Suffix, that is to say, it is "bc#sample.test" or "bc@#sample.test". In this case, confusion is avoided.

3.3 Features

• Unique: The UTID is unique because it adopts DNS to avoid name conflicts. It is never dependent on any context.
• Universal: The UTID is not designed for any special purpose and it is designed to be used in any context without any limitations.
• Open: Any organization and individual may design their own UTID coding system without any limitation from other organization. The only prerequisite is the designer should own a DNS name.
• Routing: The UTID supports two levels of routing, of which one level is IP routing by the information of DNS, and the other level is IDTP trace in the IDTP domain by the information of UTID Suffix.
• Compatibility: The UTID may compatible with existing coding system by using the exist code as id part of the UTID. For email address, we may use symbol ~ to stand for symbol @.

3.4 Some considering

For an organization, to design a UTID coding system is a complex work and needs to be designed carefully in advance. There should be a global architecture of UTID used for things owned by the organization and things that is not owned by the organization but has the obligation to provide information. Then design the UTID coding system from four aspects: dns, location, catalog, and id.

• Dns: It is recommended to use second level domain name, such as id, db, or id1. An example is id.sample.test.
• Location: The only consideration for location is to meet the traceability requirements of IDTP. For example, one dns stands for one IDTP domain that contains one or more IDTP servers. One location stands for one IDTP server in the IDTP domain. Therefore, the location shows the place of IDTP server in the IDTP domain. Another example is that a UTID "sensor@rm201.bld1#id.sample.test" stands for a small embedded IDTP server in room 201, building 1. The server acts as an IDTP bridge connecting to some sensors in the room.
• Catalog: Different things usually have different properties. A thing id different status also may have different properties. Different things in the same catalog may share some common properties. Catalog reflects the difference of these properties, which is actually data format represented by request and response class. Therefore, a catalog stands for one group (namespace) or more groups (more namespaces) of busilet, request, and response. Catalog is the many to many mapping between thing and namespace of busilet.
• ID: It is designed according to the requirement of the organization. Or use an existing one.

A thing may have many UTIDs assigned by one organization according to its location or catalog in different status or stages. For example, a temperature sensor may have its real time data and history data. When we access the real time data, we need to connect to it directly. When we access the history data, we need to connect to a database. So the UTID may be "s0001$sensor.rt@rm201.bld1#id.sample.tes<code>t" for real time data, and "s0001$sensor.db#id.sample.test" for history data.

A thing may have many UTIDs assigned by different organizations. For example, a company "sample1.test" produced a product A and assigned a UTID "a.2013$p#sample1.test" to it. When the product was sold to sales company "sample2.test", the same thing may be assigned a UTID "01$goods#sample2.test". When the product reaches a company "sample3.test" that use it as fixed assets, the same thing may be assigned a UTID "001.2013$asset#bld1#sample3.test". All of these three companies should provide information about the product but in different aspects. If company "sample1.test" has all of these UTIDs, the company should be able to trace all messages about the product. Company "sample2.test" and "sample3.test" also may exchange the UTID and keep in touch. In this way, there will never be "Information silos".

In the above sample, company "sample1.test" provides information about the product. Company "sample2.test" provides information about the sales and company "sample3.test" provides information about the usage of the product. However, all of them should have consensus on the data format that is the standard Request, Response, and Busilet in different contexts.

This is only an example. Different designers may have different concerns. Another example is a database application, location may stand for database, catalog may stand for table, and id may stand for the primary key of a record.

The major disadvantage of UTID is that it is character-based and is a little to long. So it could not be used in length limited context or number-based coding context, such as one dimension bar code.

The major disadvantage of UTID is that it is character-based and is a little too long. So it could not be used in length limited context or number-based coding context, such as one dimension bar code.

3.5 Application of UTID

The UTID may be used in many fields:

• The Internet of Things application
• Cloud computation
• Database management
• Local and remote procedure call
• And more ...

4 IDTP Protocol

The owner of UTIDs should setup one or more IDTP server, which consists a IDTP domain to provide information for all UTID it owned. So any users may access this information from IDTP client.

The IDTP protocol actual is a remote procedure call (RPC), where IDTP server is the server of RPC and IDTP client is the caller of the RPC. The client sends a call with a parameter called request and gets returned data called response. So it is a request-response model.

4.1 Design Principles

• Universal: It should support various underlying protocols, such as TCP, UDP, UDP multicast, Web Service, and HTTP, or other protocol in future, such as Bluetooth, ZigBee, to extend its application scope.
• Accessibility: It should be able to reach anywhere, including sensors that do not connect to network directly.
• Traceability: It should be able to trace a request to its target IDTP server by UTID in a IDTP domain.
• Consistency: It should be able to use a uniform mechanism to send a request, regardless of local call or remote call, regardless of different underlying protocols.
• Simplicity: It should simple enough to be used by developers, simple enough to be run in any kind of devices, even in a week computation capacity device.
• Compatibility: It should be compatible to current technology, such as Web Service.

4.2 IDTP

4.2.1 Features

• Support five underlying protocol: TCP, UDP, UDP multicast, Web Service, and HTTP
• Support encryption and authentication
• Support session
• Do not support: compress, connection, cache
• Default: character set is UTF-8, data format: JSON, and SOAP (only when communicate with Web Service)

4.2.2 Data format

The IDTP protocol use request-response model, the data has two parts: head and user’s data.

4.2.2.1 IDTP head

The head of IDTP protocol has two types: request head and response head. The fields in head are listed in Table 2.

name	Description (sample)	Request	Response	Remark
idtp	Idtp version:busilet version(0.9:1)	y	y
utid	Request UTID by client(aa#bb.cc)	y
ns	Namespace (package) of busilet (utid.com.test.box)	y
name	Name of busilet (Register)	y
code	Response status code (200)		y
len	Data length(1234)	y	y
hop	Count of hops, max is 8 (5)	y	y
hops List of hops to check loops (aa#bb.cc|bb#bb.cc)	y	y	Except UDP
enc	Encryption parameters (rsa)	y	y	TCP only

All fields in head should be in one line and ordered strictly in the table. All field names are very short to increase the efficiency. Each field is a key:value pair separated by a colon ":" and fields are separated by semicolon ";". There is no quote mark for the key and value so that no colon or semi colon is allowed in values.

4.2.2.2 Head for UDP

When using UDP as a underlying protocol, the data length has a limitation. In order to contain more user data in one UDP datagram, the head part should be as short as possible. So the head for UDP have not hops and enc fields, resulting in the loss of the following functions:

• Trace track: Hops field is used to record node name the request or response passed. It will increase dynamically and lead to the possible loss of user’s data. Fortunately, the hop field can be used to avoid loop trace.
• Encryption: Enc field is used for encryption, which will lead to longer user’s data.

4.2.2.3 User’s data

User’s data adopts JSON format. It may support other format in the future, such as XML.

Following is an example. Here is the request:

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."}

Here is the response:

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 Why JSON

Advantages of JSON:

• JSON is simple and widely used.
• JSON may be used to express any type of data.
• JSON format is shorter than XML format in data length so that saving network stream
• JSON is more efficient then XML and easy to treated in week computation capacity devices.
• JSON could be used directly by Ajax without any conversion.

Disadvantages of JSON:

• JSON contains less meta information, especially type, attribute message.
• It need format conversion when communicating with Web Service

4.2.3 Date type

For the IDTP protocol itself, user’s data can be any kind of data. However, we need to make some limitation in order to make sure both sides of the communication can understand each other.

The data type has two groups: basic data type and composite data type.

4.2.3.1 Basic data type

The IDTP protocol supports the following six basic data types:

• Integer: 32 bits integer.
• Long integer: 64 bits integer.
• Double number: 64 bits double number.
• Boolean: true and false only.
• String: It is a string with max length 64K. If the underlying protocol is UDP, the data length has more strict limitation: The while request or response including head data could not exceed the max length of a UDP datagram.
• Date: It is a ISO-8601 format string, also compatible with Web Service

<p>It is not recommend to use <code>char

, byte, short, or float type because they may cause overflow in some case. If other data type, such as super long integer, precision floating-point number, should be used, you may convert then into a string and negotiate between client and server.

4.2.3.2 Composite data type

The IDTP supports two types of composite data type: user defined class and one dimension array.

• User defined class
  • It is a common Java class with properties of the above six basic data types or another class
• One dimension array
  • Array of basic data type (except date type) or user defined class.
  • In Java, array, list, and set are the same when converted into JSON. The IDTP does not guaranty the order of the data.

4.2.3.3 Naming rule

1. Non array (basic data type and class)
   • Adopt lower camel case notation excepting the case described below.
2. Array (Array, List, and Set)

   If you don’t need to compatible with Web Service, you may use lower camel case naming method, too.

   If you want to compatible with Web Service, you need to obey the following rule because XML contains data type message and JSON doesn’t contains data type message. The result is that the name should contain data type message in IDTP:

   • Adopt Systems Hungarian notation. Following are two cases:
     • Basic data type: The prefix aoi, aol, aod, aob, and aos stands for array of int, long, double, bool<code>ean, and string. It may follow any characters beginning with capital letter. Examples are: aoiAge, aosStudenName. However, aoiage is not a name of an array. There is no array of date so that date type should be encapsulated into a class and then use the array of the class.
     • User’s defined class: The name of array of user’s defined class is stricter. (1) The prefix must be "ary"; (2) The rest must the name of the class. So the name of an array of Student class should be aryStudent. If there are more than one array for same class, you need to create several subclass the class and use the subclass name to name the arrays.
   • Some consideration
     • The first letter of classes name should be capital and the first letter of properties and methods name should be small. This is the convention in Java language.
     • None array properties could not named beginning with ary, aoi, aol, aod, aob, and aos and followed by first capital string, but could be followed by first small string. Therefore, aryBook is an array of Book class, aoiDay is an array of integer, but arybook and aoiday both are not an array.
   • Internal properties

     There are three properties are used internal. They are _attri_, _session_id_, and _utid_suffix_. Developers should not use these three properties in their codes.

4.2.4 Request

The IdtpRequest class in Busilet4j API encapsulates request head data and some methods.

The developers of IDTP Server and Client are required to extend the IdtpRequest class, and encapsulate user’s request parameters. No methods should be put in it.

4.2.5 Response

The IdtpResponse class in Busilet4j API encapsulates response head data and some methods.

The developers of IDTP Server and Client are required to extend the IdtpResponse class, and encapsulate user’s response parameters. No methods should be put in it.

4.2.6 Busilet

Each busilet has a name and a namespace (that is the package name in Java), which are included in the request head data.

A busilet is encapsulated with business logic in server side, which handles the request from client and returns the result to the client as a response object. Therefore, each busilet should implements the following method declared in BusiletExecutable interface:

IdtpResponse doBusiness(IdtpRequest idtpRequest) throws UtidException;

There is should no client business logic in a busilet.

4.2.6.1 The busilet

• Naming

  Adopt upper camel case notation.

• Business logic

  Each busilet should contain the implementation of busilet logic. It accepts a request, does the busilet logic, and then returns a response.

  Each busilet has a pair of matched request and response. For example, a busilet named "Demo" should have three classes named:

  DemoRequest: It encapsulates all request parameters.

  DemoResponse: It encapsulates all response results.

  DemoBusilet: It implements doBusiness() method, which encapsulates business logic.

4.2.6.2 Namespace

The namespace is used to group busilet and avoid the name conflicts of busilet. It is exactly same as package in Java language, namespace in C# language, and namespace in Web Service but reverse in order. One namespace may contain several busilets, just like one package may contain several classes and one Web Service may contain several methods.

It is recommended that namespace be named by using the DNS that defines the busilet and add "utid." as a prefix to indicate that the namespace is IDTP’s namespace. For example, a namespace of "utid.test.sample.sensor" stands for a group of busilet defined by organization of "smple.test" and the busilet is about information of sensors. However, in Web Service, the namespace becomes "sensor.sample.test.utid".

It is also recommended that add "utid.pub." as a prefix to a namespace to indicate that the busilets are standardized busilets by some industries. An example is "utid.pub.test.sample.sensor".

4.2.6.3 Namespace and Catalog

A busilet and related request, response is negotiated between both sides in the communication. It may be enterprise standard or industry standard. Therefore, the namespace is also a standard.

Catalog is used to group UTIDs through busilets, which give a group of busilets with same properties a same name and using same group of busilets to access the UTIDs. The catalog name is irregularities and named arbitrarily due to the various UTIDs, but namespace should be standardized.

It is very important to establish a mapping between namespace and catalog so that developers could be able to obtain a standard namespace from an arbitrary catalog name. This is done by MapCatalogBusilet and catalog_map.xml in the Busilet4j project.

4.2.6.4 Built-in busilet

The Busilet4j project provides six built-in busilets in the namespace of "org.utid.busilet":

• Infor: It is usually used to provide general information of the IDTP domain. It is the default busilet when namespace and name are omitted. It has special meaning for small smart devices, which need handle one busilet only. The default one is a best choice for it. You may redirect this busilet to another class by setting <default_busilet_class> in configuration file.
• MapCatalog: It is used to provide mapping information of catalog and namespace. The relationship of catalog and namespace is many-to-many. In the Busilet4j project, the mapping data is stored in catalog_map.xml file.
• Ping: It is a busilet for test, just like ping command in TCP/IP.
• PullFile: It is used to download files from a default directory or a directory configured.
• PushFile: It is used to upload files to a default directory.
• WSDL: It will get WSDL from an IDTP server or a Web Service server so that IDTP can be compatible with Web Service.

4.2.7 Underlying protocols

The IDTP protocol is an application layer protocol that relies on the data transfer of underlying protocols, which could be one of TCP, UDP, UDP multicast, Web Service, and HTTP. Each node may choice the underlying protocol according the requirements (efficiency, function needed, compatibility), which extends the application scope of the IDTP protocol.

These five protocols are as following:

• TCP: It is the common one. You may give it higher priority if possible.
• UDP: It is connectionless protocol with high efficiency, but has limit on length of one datagram.
• UDP multicast: It is used to multicast a request to a group of nodes. It also has limit on length of one datagram. An example is to find which nodes are active. In this case, each node might need to take the initiative to send a request to the multicast publisher to inform it through TCP protocol after a randomized time.
• HTTP: It is used for a browser access IDTP server through Ajax technology.
• Web Server: It is used for compatible with Web Service to conduct communication each other.

The underlying protocol may be extended, including wired communication and wireless communication.

4.2.7.1 TCP

The advantage is stable and reliable, suitable for transferring large amounts of data, or supporting encrypted transmission. The disadvantage is high overhead due to the three-way handshake, not suitable for real-time context.

TCP, HTTP and Web Service may share a same port number, which is also used to WSDL discovery.

4.2.7.2 UDP

The advantage is high speed and low overhead, suitable for real time transferring. The disadvantage is low reliability, limited data transferred in one datagram.

The IDTP do not send a request or return response in multi datagram using UDP protocol. Each request and response should be limited into one datagram.

4.2.7.3 UDP multicast

The advantage is that you can broadcast to all nodes within the IDTP domain, such as publishing a notice, or query the name of active node. The disadvantage is that it is only one-way transfer. However, you could ask the receiving node to send a new TCP-based request to the multicast publisher after a random delay time.

The IDTP do not send a request or return response in multi datagram using UDP protocol. Each request and response should be limited into one datagram.

UDP Multicast transfer is limited in a LAN, and can not trace through IDTP server. But you can trace a request through IDTP server using UDP-based and multicast it at the last stop.

4.2.7.4 Web Service

The ns in IDTP and namespace in Web Service are exactly same except in reverse order. One Web Service has one namespace and several methods. The IDTP in one ns has several busilet. So a method in Web Service is same as one busilet in IDTP. The name of the method in Web Service is the name of busilet in IDTP.

For the compatible of IDTP and the Web Service, Web Service should also have some compromises. A method that compatible with IDTP should have two parameters: one is UTID string and the other is request that encapsulates all parameters. The method that compatible with IDTP also returns one response object, just like what is done in IDTP.

When making configuration for Web Service, you need to add the URL of the Web Service to the configuration.

4.2.7.5 HTTP

If you adopt HTTP as underlying protocol, there are two implementations:

• Integrated with IDTP: The IDTP Server may use its TCP port to emulate HTTP service and provide HTTP-based IDTP service. But this is not suitable for Ajax to access it because of the domain cross problem.
• Integrated Web Server: In this case, you may declare a path in the URI to provide IDTP service. All HTTP request to the URI will be considered as an IDTP request. The advantage is that the IDTP process shares with the Web server process and increases the efficiency.

Usually an IDTP integrated with HTTP is the final step in the trace routing. In this case, the request will not forward (trace) again.

The biggest advantage of HTTP-based IDTP protocol is that it allows any browser to access the IDTP server through Ajax technology.

In addition, an IDTP server may embed into a Web server to provide IDTP service, but use another independent port number. In this case, the underlying protocol is still TCP or UDP, rather than HTTP. Here is some code to show how to do so in tomcat server:

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);
	}
}

The IDTP server starts using IDTP port number when tomcat server starts, which use HTTP port number.

4.2.8 About Google App Engine

Java language is a program language in Google App Engine. The IDTP protocol may be implemented on Google App Engine and provide IDTP service through HTTP protocol.

4.2.9 IDTP Discovery

The IDTP is compatible with WSDL of Web Service so that IDTP could be able use UDDI discovery of Web Service. It provides a broad developing space for IDTP.

4.3 IDTP Server and Client

4.3.1 IDTP Server

The features of an IDTP server are:

• Provides message about the IDTP domain by a built-in Infor request.
• Provides namespace list that a catalog mapped bya built-in MapCatalog request.
• Provides WSDL message for a namespace by a built-in Wsdl request.
• And the final but most important is that it runs business logic in Busilet when received a request.

The core of an IDTP Server is Busilet that provides RPC service. Each IDTP server should have one or more Busilet for each catalog of UTID.

In object-oriented programming languages, such as Java, Busilet is a class with the following basic structure:

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;
	}
}

An IDTP server may have various Busilet classes, which are grouped by namespace (package). The Busilet, Request, and Response should be in same namespace (package) and same name but ending with Busilet, Request, and Response respectively.

In addition, the Request and Response classes should be exactly same in IDTP server and IDTP client. A Busilet may be omitted in IDTP client.

In Busilet4j project, it is easy to start DTP server:

// 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();

The configuration file is idtp.xml, which have to be read on start.

4.3.2 IDTP Client

The features of an IDTP client are:

• If client knows which request should be used to communication with the server, send the request directly.
• If not, a client may send an Infor request to look for the general message of the IDTP domain the UTID belongs.
• If not, a client may also send a MapCatalog request to get the mapped namespace of the UTID.
• If not, a client may also send a Wsdl request to get all request and response meta data of a namespace.
• Finally, the client should know which request should be used to communicate with the server.

An IDTP client sends a request to call Busilet on IDTP server and handle the response. It is important to point out that the UTID in a request is the key because of the trace message it contains. The IDTP protocol will not work without the trace message of UTID. The IDTP protocol becomes useless without UTID.

4.4 Encryption and Authentication

Data security is an important issue in the data communications, especially in the condition of forwarding by many nodes. Here we discuss encryption and authentication only. We suggest that more security issues be discussed when possible.

4.4.1 Design Principles

• Compatibility: Adopt common encryption algorithms, which could be used in different platforms.
• Security: Adopt encryption algorithms with high strength to ensure secure communications.
• Universal: Encryption and authentication need high computation cost. The IDTP protocol is a universal and ubiquitous protocol, suitable for devices with week computation capacity. Therefore, the solution for security should also be able to be run in such devices.

4.4.2 Encryption and authentication technology

4.4.2.1 Encryption technology

We suggested two encryption technologies:

• XOR encryption: This is a very simple encryption technology and exchange password manually. It suitable for small devices in a relative security context.
• AES encryption: This is 128 bit AES encryption technology and exchanged AES key by public key technology (RSA algorithm). It is one of the most common encryption algorithm and suitable for most applications.

You may establish a trace routing by use this two encryption methods to meet various requirements. For example, a small smart device connects to an IDTP server by XOR encryption and the IDTP connect to another IDTP server by AES encryption.

4.4.2.2 Authentication technology

Encryption technology may be used as authentication. But XOR and AES encryption have some different:

• XOR encryption can used to authenticate each other. The successfully decrypting encrypted data means authentication success. It is two way authentications.
• AES encryption use certification to exchange AES key. But this is not authentication. It requires a method to verify the digital certificate of other side. So both server and client should have its certification and both sides should have the ability to verify other side’s certification.

4.4.3 XOR encryption

It is a very simple and insecurity encryption technology. It is only used in a small device with week computation capacity in relative security environment. It is not allowed to be used in continue two connections for security reason.

4.4.3.1 Password negotiation

It requires that the client and the server to exchange password manually and saved in the configuration file. The password should be a 32 to 64 byte array, which converted into base64 encode string. Common passphrase is not allowed in the password for security reason. The password negotiation is conducted in neighbor nodes, so that it can encrypt data between neighbor nodes only.

The Busilet4j project provides createXorPassword() method in SecurityTool class to generate such password.

The password is saved in configuration file both in server and client end.

4.4.3.2 Encryption and decryption

Encryption: First calculate the crc32 value of the original data that is to be encrypted. Then send the encrypted ciphertext and crc32 value to other side.

Decryption: First decrypt the ciphertext using saved password. Then calculate the crc32 value of the decrypted plaintext. Decryption is success only if crc32 check is success.

The crc32 algorithm is same as that used in zip compress algorithm.

4.4.3.3 Client

Before sending a request, a client searches the saved password and encrypts the data. Then send the request in following format:

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

Where enc field is used to inform the server the encryption algorithm, CRC32 value, and the sender's node name. Each parts separated by commas without spaces in them.

4.4.3.4 Server

Upon receipt of a request from a client, the IDTP server gets the sender's node name from the header and looks for the saved password of the node and decrypts the ciphertext.

The response should be encrypted using same password and returned in the following format:

head fields;enc:xor,crc32
ciphertext

No node name is need in returned data.

4.4.4 AES encryption

AES is a security encryption technology. We use digital certification and public key technology (RSA) to negotiate the AES key to increase the security.

You may use commercial certifications or internal certifications. The former is suitable for communication between IDTP domains and the later is suitable for communication in a IDTP domain. AES encryption could be used to end to end encryption that greatly increases the security.

The Busilet4j project provides some methods in CertificationTool class to generate a certification and sign a certification.

4.4.4.1 Key negotiate

Server certification is used both for key negotiation and server authentication. Client certification is used for client authentication only. Therefore, client certification is optional in AES encryption.

In order to increase the efficiency, we use one request-response to finish the whole key negotiation process. Key negotiation is initialized by client:

• A client sends a key negotiation request (EncRsaNegotiateRequest), which contains target namespace, a 128 bit random number, and a optional certification.
• The server optionally verifies the client certification, generate a AES session key from the random number of the request and a random number of itself, generate a session key ID. Then the server encrypts the AES session key using its private key. Finally the server send back server certification, session key ID, encrypted AES session key, and a matched utidSuffix back to the client.
• The client optionally verifies the server certification, decrypt the AES session key using the server certification. Key negotiation is finished and optional authentication finished.

In the Busilet4j project, the key negotiating is encapsulated in EncRsaNegotiateBusilet class. The possible result including following:

• Fails: The reasons may be: network fails, server fails, configuration fails, and system fails.
• Success without authentication: Key negotiation is success, but authentication fails. The reasons may be: certification expired, client doesn’t have certification.
• Full success: Both key negotiation and authentication are success.

4.4.4.2 Save of session key

After a success key negotiation, both server and client have a copy of the session key, which is dynamically negotiated so that we should not save it into a file.

• In the server side: Save the session ID and session key in a static Map property in EncRsaNegotiateBusilet class.
• In the client side: Save the utidSuffix and session key with session ID in another static Map property in EncRsaNegotiateBusilet class.

4.4.4.3 Client

Before a client send a request, it look for the session key by using UTID message in the request to find a match utidSuffix and get the session key and session ID. If none is found, that means there is no key negotiated between the client and the server so a new key negotiation starts.

Then the client uses the session key to encrypt the request data and sent it out in the following format:

head fields;enc:rsa,session kek ID
ciphertext

Where enc field is used to inform the server the encryption algorithm, and the session key ID. Each parts separated by commas without spaces in them.

In some case, a client may have a session key but the session key has been invalid in server side. It is occurred when session key has bee timeout, or server restarted. In this case, the server will return a response to inform the client the encryption is failed and the client should be start a new key negotiation process.

4.4.4.4 Server

Upon receiving a request, the server will look for session key by the session key ID in the request head. Then decrypt the request data.

The response should be encrypted using same session key and returned in the following format:

head fields;enc:rsa
ciphertext

No node name or session key ID is need in returned data.

4.4.5 Encryption and trace

If a communication is between two neighbor nodes, the encryption and authentication is simple. But in the process of trace, a request may trace through many nodes. In the trace forwarding, there will be security problem is some node encrypt the data and other do not encrypt the data. To avoid such bug, the IDTP protocol provided following rules for trace:

• Encryption and decryption is for data part, not for protocol head.
• Whether a request is encrypted is decided by the one who create the Busilet, setting in the Request.
• If a request is encrypted, then the response must also be encrypted, and is encrypted using the same algorithm.
• A tracing node can not decide whether a request is encrypted. A tracing node must forward a request in encrypted form if it received it in encrypted form. At the same time, A tracing node must forward a request in non-encrypted form if it received it in non-encrypted form. If a server received a request in non-encrypted but the request should be encrypted, the server will return an error message without forwarding it further.
• A tracing node may decide the encryption algorithm of a request if it should be encrypt. The tracing node may directly forward it or decrypt it and then encrypt it using another algorithm (never use same algorithm) before forwarding. It is up to the configuration of the node set by administrators.

4.4.6 Features

• A request is either encrypted in all nodes or non-encrypted in all nodes. It is absolutely not allowed that encrypted in some nodes and non- encrypted in other nodes. In this case, forwarding is terminated and an error message returned.
• The encryption algorithm is not negotiated by a client and a server. It is decided by the configuration of the node set by administrators. Both requester and responder could not determine the encrypt algorithm and don’t know which algorithm has been used.
• The security and encryption strength is fully decided by the configuration of each node set by administrators.
• Only TCP-based communication support encryption. The encryption chain could not be established even if only one node doesn’t support TCP.

4.5 Traceability

Traceability is a core concept IDTP protocol so that we can say the UTID and IDTP will lost their value of existence if there is no traceability mechanism.

There are two levels of trace:

• IP routing: It is the process that a request is forwarded to the IDTP domain by the message in UTID of the request in the TCP/IP network.
• IDTP tracing: It is the process that a request is forwarded to the target IDTP server in the IDTP domain by the message in UTID of the request in a network not only consists of TCP/IP (such as ZigBee).

IDTP tracing is completely a new concept that a request is forwarding in an IDTP domain regardless the IDTP domain is within in a LAN or across WAN. A typical IDTP domain is the LAN of the owner of UTIDs. However, it can be extended into WAN, such as a remote host owned by the owner and it also may inward into a network of non-TCP/IP, such as a smart device connected by Bluetooth or ZigBee through a trace bridge.

IDTP tracing is independent to IP address or DNS name. It is dependent to UTID and the tracing configuration of an IDTP node only. Therefore, the forwarding scope of IDTP tracing is independent to IP subnet or DNS architecture. This is to say, IDTP established a full new independent network for IDTP tracing in application layer based on the Internet.

This paper will not discuss the TCP/IP routing.

The IDTP Traceability technology includes two technologies: trace gate and trace bridge, which is different and used in different context.

4.5.1 Trace gate

A trace gate is an IDTP Server, which trace (forward) a request to target IDTP server in an IDTP domain. It might conduct the conversion of data format, or encryption and decryption.

In theory, the forwarding is based the location part of a UTID. But in practice, the forwarding is based on not only location part of UTID but also the last part of a UTID, which is called UTID suffix (UtidSuffix). This lead to some advantages: (1) Make the design of UTID more easy. Sometimes, catalog or part of id may be used as a foundation where location may be omitted and short the length of UTID. (2) Make the trace rule more flexible.

As an important concept in UTID, location introduces the concept of trace. In the implementation, location part is diminished or even may be omitted, but it is still the core concept in UTID and IDTP.

4.5.1.1 Trace forward

There are two meaning when a trace gate forwards a request:

• Look for the next hop address by match UtidSuffix and UTID in the request. Then the request will be forward to the address.
• Look for the trace parameter (underlying protocol, port number, and so on) from configuration file set by administrators. Then forward the request the address using this parameters.

A trace gate may have three possibilities when received a request:

• Local process: If the next hop address is local (marked by #), so it is a local request and will be processed by the same server in same process.
• IDTP trace: If the next hop address is found but is not local. Then forward it to the next hop. The next hop may be within same IDTP domain or anther IDTP domain.
• IP routing: If the next hop address is not found. In this case, the request will be unconditionally forward to the default port number (25604) of the dns of the UTID in the request by TCP protocol without encryption.

4.5.1.2 Tracing table

Two factors should be considered when forwarding a request:

• Next hop address: That is: Where to go? It is determined by the match of UTID and UtidSuffix.
• Trace parameter: That is: How to go? It is determined by the namespace in the request.

Therefore, trace gate use a tracing table to save all these messages used to trace a request. The tracing table consists of several tracing item. Each tracing item has two parts:

• Tracing Track
• Tracing Param

1. Tracing Track

   The tracing track is used to save the next hop address. There are two type of tracing track:

   (1) Forward tracing track: It is consists of three parts:

   • UtidSuffix: It is used to match target UTID. An utidSuffix may:
     1. Contain last part of a UTID;
     2. Contain only dns part. In this case, the symbol # could not be omitted.
     3. Contain symbol # only. It means match any UTID like a wildcard.
   • nextHopAddress: The address (IP address or DNS) of next hop.
   • Tracing param: A reference name to tracing parameter. See bellow.
   • Local track: It has UtidSuffix only. It has no next hop address and tracing parameter. However, the UtidSuffix can not be "#", which means all UTID are treated by local.

   Something to be considering:

   • Both of UTID and UtidSuffix should be in full format when matching them. For example, a UTID "123$sensor#sample.test" should be converted to "!123$sensor@#sample.test" and "123#sample.tes" should be converted to "!123$@#sample.test". An UtidSuffix "sensor#sample.test" should be converted to "sensor@#sample.test" or "sensor$@#sample.test" or even "!sensor$@#sample.test" dependent on the match requirements. This is to avoid the confusing when matching UTID and UtidSuffix.
   • A next hop address of "127.0.0.1" doesn’t mean local track. It means forward to anther port number of the same machine by forwarding process. Only a next hop address of "#" means local track and be treated in the same process in the server.

   Match of UTID and UtidSuffix:

   • Convert both UTID and UtidSuffix into full format, and match the UTID whether ended with UtidSuffix by using endsWith() method of String class. The match order is sorted by the length of utidSuffix, the longest match first.
   • If match fails, then match symbol #. It matches any UTID.
   • If fails again, then forward to default port number (25604) of DNS using TCP protocol without encryption.
2. Tracing Param

   The tracing parameter is used to save the parameters of tracing. The tracing parameter is coupled with namespace. One namespace has no more than one tracing parameter and several namespaces may share same tracing parameter. A tracing parameter has two parts:

   • Namespace: It indicates the namespace of the tracing parameter. A star symbol (*) match any namespace.
   • Protocol parameters: There are five underlying protocols. Each of them have different parameters:
     • TCP: port number.
     • TCP with XOR encryption: port number and reference name of password.
     • TCP with AES encryption: port number and reference name of certification
     • UDP: port number.
     • UD: port number and multicast address.
     • HTTP: port number and path.
     • Web Service: port number and path.

   Note: The protocol parameter could not be with encryption option if utidSuffix is symbol "#" because that means send an encrypted request to any other IDTP server. You should make sure that the IDTP server is able to handle encrypted request when you set encryption option.

3. Configuration of trace table:

   There are two ways to configure the trace table in the Busilet4j project:

   • Hard code in program: It is to use method in IdtpConfig class to configure everything in program. It is simple and is recommended only for testing.
   • Configuration file: The configuration file is idtp.xml in Busilet4j project. The readConfig() in IdtpConfig class is used to read configuration file. It is more flexible and is recommended for all purpose.

4.5.1.3 Change of encryption algorithm

Change of encryption algorithm happens only in TCP-based communication. The change should be XOR to AES or AES to XOR. There will never be change between XOR and XOR or AES and AES.

It should return error message when change of encryption occurred in non-TCP-based communication.

4.5.1.4 Conversion of data format

A request may be needed to be converted when underlying protocol changes.

• Encrypted request could not be converted because only TCP-based support encryption. If it happens, the forwarding is terminated and an error message should be returned.
• If data length exceeds the limit of UDP datagram when converting to UDP-basis, the forward is terminated and an error message should be returned.

4.5.1.5 Avoiding loop tracing

Loop tracing may be occurred because of the consistency of configurations of each node. The IDTP protocol uses hop count to avoid loop tracing. If hop count reaches max value (default is 8), the forward is terminated and an error message should be returned. There is another head field hops in TCP-based communication to record the tracing node name that can be used to debug.

4.5.1.6 Tracing conflicts

Tracing conflicts may be occurred because of the consistency of configurations of each node. In this case, a same UTID may be traced to different server from different client, leading to different results.

The IDTP doesn’t provide any solution to avoid it. Therefore, the administrators should be careful when designing the configuration of each node in an IDTP domain.

4.5.1.7 Features

Regarding to the IDTP tracing, programmer and administrator have clear responsibilities. The programmers are responsible only for sending requests and receiving the request. They are not necessary to or able to concern about the traceability process.

• The programmers of client could not know how the request is forwarded when sending a request. They concern the value of UTID only, which determines where the request forward. They don’t need to concern about encryption, authentication, and forwarding parameters.
• The programmers of server could not know where a request come form and how the request was forwarded. They know a request is local or remote only without any other information about encryption, authentication, and forwarding parameters.

Administrators are responsible for the configuration of each node by editing configuration file idtp.xml.

• Forwarding of a request is determined by configuration only, including encryption, authentication, and forwarding parameters.
• A client must be a trace gate so that the client may handle local or remote request.

4.5.2 Trace bridge

A trace bridge is an IDTP server, which is placed in the boundary of an IDTP domain and non-IDTP devices. A trace bridge acts as a bridge between an IDTP domain and non-IDTP devices and provides data communication between them, including data collection, data conversion, and UTID mapping.

A trace bridge communicate to non-IDTP devices, such as RFID reader, barcode scanner, through not-TCP/IP network, such as WSN, serial port, and industry bus.

A trace bridge should responsible for maintaining a mapping of UTID and device number so that each device will have a UTID identifier.

The functions of a trace bridge are as following:

• Date collection: Upon the receipt of a request, collect the data of the device indicated by UTID and return the data back.
• Action operation: Upon the receipt of a request, send an operation command to the device indicated by UTID and return the operation status back.
• Data reporting: Collect the data of a device regularly and send the data to an IDTP server.

These functions are customized functions, which are implemented according the requirement of devices.

4.6 Session

Session is a built-in feature in the IDTP protocol. The IDTP session is similar to HTTP session.

5 The implementation of IDTP

The Busilet4j project is a reference implementation of IDTP protocol. The design and revise of IDTP protocol and the implementation of Busilet4j is conduct simultaneously. Since the Busilet project initiation in 2011 and first release of Busilet project in sourceforge.net in June, 2012, the IDTP and UTID experienced numerous redesign, reconstruction, and revision. At the same time, the Busilet also experienced numerous redesign, refactor, and modification. I didn’t publish any new release of Busilet on sourceforge.net for these reasons.

Now I am pleasure to publish a new release both on sourceforge.net and code.google.com when the IDTP and UTID become mature, although the busilet is still need to be improved.

The Busilet4j project is written using Java language. However, it has some special code designed to be converted into C# automatically. I hope the Busilet4j project could be converted into C# project automatically and keep the code synchronized between Java and C#.

5.1 System design

The system design is based on IDTP and UTID, which is discussed earlier.

5.2 Package structure

There are five packages in the project:

org.utid: It contains Utid class and UtidException class only.

org.utid.busilet: It contains classes that declare Busilet class, Request class, and Response class. And there are six built-in busilet.

org.utid.idtp: It is the core of IDTP. It implements five underlying protocol, tracing, key negotiation, encryption and decryption, session. There is also a IdtpConfig class that is responsible for the configuration of IDTP.

org.utid.javacsharp: This is for C# language. The classed in this package encapsulate the difference between Java and C#.

org.utid.tool: It provides four tools for developers. Class BusiletTool is used to generate Busilet, Request, and Response. Class CertificationTool is used to generate digital certification and sign certification. Class CsharpTool is used to convert the source code into C# code, which does not work properly at present. Class DatabaseTool is used to generate some DAO, Busilet, Request, and Response from hibernate database model.

5.3 Detail design

Only two key issues are discussed here.

5.3.1 Session

The session is end to end. All codes related to session are in IdtpSession class and BusiletDispatcher class.

Session is independent to forward. Forwarding should make sure to keep the value of sessionId. Session is exists in TCP-based and UDP-based, and exists in local call and remote call. The uniform interface for local call and remote call allows programmers more easily to write program both for local call and remote call.

5.3.2 Forward and encryption

• Local to local: No encryption. It handled in BusiletDispatcher class.
• Remote to local: First decrypt the request, after local treatment, encrypt the response and return it. It is handled by acceptRequestByTcp() method in TraceGate class.
• Remote (also local) to remote: It divided into three stages:
  • Before forward: Decrypt the request if it is XOR encrypted then encrypt it using AES algorithm. If the request is encrypted by AES, then just forward if next hop is not XOR or decrypt it and encrypt it using XOR algorithm.
  • Forward: Forward the request without any special treatment.
  • After forward: That is the treatment of response. It is the exactly the reverse operation.

5.4 Features not implemented

There are some features not implemented in the Busilet4j:

• Authentication of server and client certification.
• Compatible with Web Service: It works in the earlier version. However, it may be not work after a big revision.
• HTTP-based: It works in the earlier version in tomcat server. However, it may be not work after a big revision. It will be difficult to implement it in ASP or PHP.
• Generate WSDL file from IDTP server.
• Convert to C# project automatically
• Filters:

5.5 JUnit test

The Busilet4j project provides some JUnit test. Here is a list from simple to complex:

• test.org.utid: test utid, request, and response.
• test.org.utid.simple: This is the simplest one.
• test.org.utid.session: This is similar to the above, but adds session function.
• test.org.utid.encrytipn.xor: This is XOR encryption test. Encryption is only available to TCP. So the local and UDP communications are not encrypted.
• test.org.utid.encrytipn.rsa: This is RSA-AES encryption test. Only TCP is provided.
• test.org.utid.trace: This is for trace test. First run all four servers, and then run TestTcpCall.
• test.org.utid.trace.encryption: This is for trace test with XOR and RSA-AES encryption. First run all four servers, and then run TestTcpCall.

There one tutor sample in package test.sample and utid.test.sample.

5.6 Usage description

There is no user manual at present, which is already in my plan in three months. Here we discuss two key issues.

5.6.1 Design of UTID

The design of UTID in an IDTP domain is very important. It is fully discussed in section 3.4 of this paper.

5.6.2 Trace rule

The IDTP has two levels of routing. The important one is trace rule. Here is an example:

<?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 Application of IDTP

The IDTP and UTID technology can be used widely in computation including:

• Program technology: RPC, local call, Web Service.
• Research: Database management, distributed computation, grid computation, and cloud computation.
• Application fields: The Internet of things (IOT), the Internet of vehicle (IOV), supply chain management, product traceability, food traceability, etc.

6.1 Local call and remote call

It eliminates the boundaries of a local call to a remote call. A programmer may call a local or remote procedure in the same way. It will influence the design of computation.

6.2 Database technology

The UTID can be used in primary key and foreign key in database. Any one may search the information of a foreign key tracing to its original. So the foreign key here is a traditional foreign key. It is a distributed foreign key or tracing key. It will influence the concept and design of database technology, especially used in food traceability, supply chain management.

6.3 TCP/IP

The IDTP is based on TCP/IP but not TCP/IP. It established an independent network over TCP/IP with an independent forward mechanism of trace gate and trace bridge. It might be used in Internet of things (IOT), the Internet of vehicle (IOV), and mobile Internet.

7 Conclusions

Here is a simple SWOT Analysis

• Strength: It is open, universal, flexible, and traceable. The trace is a completely new concept and technology.
• Weakness: It is a new comer and need time for people to recognize and understand it. The UTID is character-based and IDTP is Json-based, so some people will not like it for various reasons.
• Opportunity: The developing of the Internet of Things needs new idea and new concept to meet new challenges.
• Threat: Standardization of the Busilet for different purposes, such as industries, categories, and usages. The ITDP and UTID will have no values without the standard for busilet. So the bottle neck for IDTP development is the standardization of the Busilet.

Simple makes the world.

The principles that governing the complex world are simple, which are physical, chemical, or biological. The author of this paper had been an idea from childhood to explain the complex world using simple principles.

The UTID is simple and the IDTP is simple. The author does hope these simple blocks may build a complex computation world.