CN107040616B

CN107040616B - Conversion method and message receiving and transmitting method for TCP/DN/IP network compatible with TCP/IP network

Info

Publication number: CN107040616B
Application number: CN201610081189.0A
Authority: CN
Inventors: 李实�
Original assignee: Individual
Current assignee: Individual
Priority date: 2016-02-04
Filing date: 2016-02-04
Publication date: 2020-01-10
Anticipated expiration: 2036-02-04
Also published as: CN107040616A

Abstract

The invention discloses a conversion method and a message receiving and sending method for a TCP/DN/IP network compatible with a TCP/IP network, which can transparently convert a message sent by an application program between TCP/IP encapsulation and TCP/DN/IP encapsulation. The technical scheme is as follows: by designing an encapsulation/decapsulation flow different from an OSI network model and utilizing a pseudo address technology, an IP message sent by an application program is transparently converted into a message in a TCP/DN/IP encapsulation format, so that the IP message can be normally forwarded between different IP domains defined by a TCP/DN/IP protocol and can be normally restored at a receiving end. Therefore, the TCP/DN/IP protocol can be completely and compatibly applied to bear the traditional network application program realized based on the TCP/IP, and the upgrading process becomes extremely smooth.

Description

Conversion method and message receiving and transmitting method for TCP/DN/IP network compatible with TCP/IP network

Technical Field

The invention relates to the internet technology, in particular to the technology related to IP network address space expansion.

Background

IPv4 is a network designed for the us military that uses only 32-bit addresses, accommodating up to less than 43 billion hosts. With the rapid expansion of IP networks, IPv4 addresses have been exhausted.

The industry has introduced NAT technology and IPv6 technology in order to solve the problem of insufficient addresses. However, NAT technology breaks the symmetry of the network, and IPv6 has great difficulty in popularization because of incompatibility with existing networks.

An article published in telecommunication science 2014 8, a dual network layer scheme-a brand new next generation internet solution-introduces a brand new solution to address shortage of IPv 4. The scheme longitudinally expands a new layer on an IP protocol stack, can expand an infinite address and simultaneously keep high compatibility with the existing IPv4 network, and is a good scheme for solving the problem of insufficient IPv4 network addresses.

However, this solution also has a problem: when the ISP is upgraded to a new IP domain required by the TCP/DN/IP protocol, because the type of a mainstream operating system is limited, a host in the domain can be easily upgraded to a TCP/DN/IP protocol stack through an upgrading operation, but the variety of application software on the host is large, the host is generally difficult to update completely in a short time, and part of the application software which is not maintained any more can not be upgraded even ever to support the TCP/DN/IP protocol stack. The application which can not be upgraded in the TCP/DN/IP network can not access the host outside the current IP domain, so the problem of not smooth upgrading still exists objectively.

Specifically, in the open systems interconnection reference model OSI designed by the international organization for standardization ISO, the network is divided into 7 layers. When data is transmitted, the data is sequentially transferred from a higher layer to a lower layer, and each layer regards the content transmitted from the upper layer as data, adds its own header, and transfers the data to the lower layer. At the receiving end, data is transmitted from the lower layer to the upper layer, and the header attached to the upper layer is stripped off each time and then transmitted to the upper layer.

The communication process of a typical TCP/IP protocol is shown in figure 1. In a specific implementation, since the host domain name is frequently used in network access, an application program needs to resolve the domain name into an IP by itself through a DNS, and then transfer the IP, the transport layer protocol type, and data to be sent to a sending function provided by an operating system protocol stack. The operating system protocol stack encapsulates the message header layer by layer and sends the message according to the principle shown in fig. 1.

The TCP/DN/IP protocol adds a UDP header and a domain name layer header to the stack. When a host assembles a domain name layer header of a TCP/DN/IP message, a domain name of a target host needs to be filled, so that when a protocol stack sending function is designed, an application needs to directly transmit the domain name, a transmission layer protocol type and user data of the target host as parameters. After the packet is passed from the domain name network layer to the IP network layer, the domain name still needs to be resolved into an IP address so as to fill in the destination address field of the IP header. At this time, the network protocol stack of the operating system should directly call the function of the gethostbyname class to resolve the domain name into an IP address at the IP network layer.

FIGS. 2A and 2B show an internal flow diagram of standard TCP/DN/IP protocol stack functions. Referring to fig. 2A and 2B, the send () function in the figure refers to all functions provided by the network protocol stack and having a function of sending a message. In this flowchart, the case where the user directly uses the IP address as the target call function is considered. If the user calls by using the IP address or finds that the target host is not upgraded after domain name resolution, the traditional TCP/IP encapsulation form is still selected. The encapsulation of TCP/DN/IP will only be selected if the user makes a call using the domain name and the target host has been upgraded.

However, this standard packaging approach has a problem: the interfaces for the TCP/IP stack based transmit function and the TCP/DN/IP stack based transmit function are different. The TCP/DN/IP protocol stack requires that the application, when invoked, pass in the target host domain name instead of the IP address. If the application only has an IP address in it, the protocol stack will not be able to fill the domain name layer because of missing domain name information (especially, there are cases where a large number of domain names are resolved to the same IP in the TCP/DN/IP architecture). Conventional TCP/IP based network applications will not be able to be carried on a TCP/DN/IP network.

Disclosure of Invention

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

The invention aims to solve the problems and provides a conversion method, a message sending method and a message receiving method for a TCP/DN/IP network compatible with a TCP/IP network, which can transparently convert a message sent by an application program between TCP/IP encapsulation and TCP/DN/IP encapsulation.

The technical scheme of the invention is as follows: the invention discloses a conversion method for a TCP/DN/IP network compatible with a TCP/IP network, which comprises a flow of sending a message by an application program and a flow of receiving the message by the application program, wherein:

the process of sending the message by the application program comprises the following steps:

the application program calls a system protocol stack to analyze the domain name of a target host as an IP address through a DNS, the protocol stack analyzes and checks an analysis result, and if the returned result indicates that the target host is not updated or is updated but is in the same IP domain as the host in which the application program is positioned, the IP address obtained by analysis is returned to the application program; otherwise, inquiring a corresponding table entry in an address translation table according to the domain name of the target host and the IP address obtained by analysis, if the corresponding table entry does not exist, firstly allocating an unused pseudo IP address from a pseudo address pool, newly adding a table entry comprising the domain name of the target host, the IP address obtained by analysis and the newly allocated pseudo IP address in the address translation table, and returning the pseudo IP address to an application program as a DNS inquiry result;

when an application program sends a message, a protocol stack compares a target host IP address in an IP header with a pseudo IP address column in an address translation table, if a corresponding table entry does not exist, the message is encapsulated by using a TCP/IP protocol stack, if the corresponding table entry exists, a target host domain name and an analyzed IP address of a target host are taken out from the corresponding table entry, a domain name layer header is added to the message and is filled in the domain name of the target host, a UDP header is added, and the target address of the IP header is changed into the analyzed IP address of the domain name of the target host;

sending a message of a bottom layer;

the process of receiving the message by the application program comprises the following steps:

the application program receives a message from the bottom layer;

the protocol stack judges whether the message is TCP/DN/IP encapsulation, if not, the standard IP message is directly received;

if the package is TCP/DN/IP, then:

extracting a source host domain name from a domain name layer and analyzing the source host domain name to obtain a corresponding IP address, or directly extracting the source IP address from the IP layer as an analyzed IP address of the source host domain name;

looking up a domain name of a source host in an address translation table, if a corresponding entry exists, taking out a corresponding pseudo IP address, and if the corresponding entry does not exist, adding an entry in the address translation table, wherein the contents comprise: newly allocating an unused pseudo IP address from the pseudo address pool, extracting a domain name of a source host from a domain name layer, and correspondingly resolving the IP address; and

removing TCP/DN/IP encapsulation in the message, restoring the received message into a standard IP message and changing the source IP address into a corresponding newly allocated pseudo IP address;

the protocol stack submits the message to the application.

According to an embodiment of the conversion method for the TCP/DN/IP network compatible TCP/IP network of the present invention, the pseudo address pool is composed of pseudo IP addresses which can not be really used for network access, the table entry of the address translation table includes the pseudo IP addresses, the domain name and the resolved IP address, and the correct domain name of the target host is provided when the message is expanded from TCP/IP encapsulation to TCP/DN/DP encapsulation by using the address translation table and the pseudo IP address thereof.

According to an embodiment of the conversion method for the TCP/DN/IP network compatible TCP/IP network of the present invention, if a message sent by an application program carries a source host IP address in an application layer, the message is converted into a source host domain name address before being sent out, wherein the format of the message is adjusted to ensure that a receiving end restores address information of the application layer, and the domain name address in the application layer is converted back to a pseudo IP address by using an address conversion table after the message reaches a target host.

According to an embodiment of the conversion method for the TCP/DN/IP network compatible TCP/IP network of the present invention, the address translation table deletes the entries that are no longer used based on the time aging mechanism.

The invention also discloses a message sending method in the TCP/DN/IP network compatible with the TCP/IP network, which comprises the following steps:

the application program calls a system protocol stack to analyze the domain name of the target host as the IP address through the DNS, the protocol stack analyzes and checks the analysis result, if the returned result indicates that the target host is not upgraded or is upgraded but is in the same IP domain as the host in which the application program is positioned, the IP address obtained by analysis is returned to the application program, otherwise,

inquiring a corresponding table entry in an address translation table according to the domain name of the target host and the IP address obtained by analysis, if the corresponding table entry does not exist, firstly allocating an unused pseudo IP address from a pseudo address pool, newly adding a table entry comprising the domain name of the target host, the IP address obtained by analysis and the newly allocated pseudo IP address in the address translation table, and returning the pseudo IP address to an application program as a DNS inquiry result;

when an application program sends a message, a protocol stack compares a target host IP address in an IP header with a pseudo IP address column in an address translation table, if no corresponding table entry exists, the message is encapsulated by using a TCP/IP protocol stack, if the corresponding table entry exists, a target host domain name and an analyzed IP address of a target host are taken out from the corresponding table entry, a domain name layer header is added to the message and is filled in the target host domain name, a UDP header is added, and the target address of the IP header is set as the analyzed IP address of the target host domain name;

and carrying out message sending of the bottom layer.

According to an embodiment of the method for sending the message in the TCP/DN/IP network compatible with the TCP/IP network, the pseudo address pool is composed of pseudo IP addresses which cannot be really used for network access, the table entry of the address translation table comprises the pseudo IP addresses, the domain name and the resolution IP address, and the correct domain name of the target host is provided when the message is encapsulated and expanded from TCP/IP to TCP/DN/DP by utilizing the address translation table and the pseudo IP addresses.

According to an embodiment of the method for sending a message in a TCP/DN/IP network compatible TCP/IP network of the present invention, the address translation table deletes entries that are no longer used based on a time aging mechanism.

The invention also discloses a message receiving method in the TCP/DN/IP network compatible with the TCP/IP network, which comprises the following steps:

the application program receives a message from the bottom layer;

if the package is TCP/DN/IP, then:

extracting a domain name of a source host from a domain name layer and analyzing the domain name to obtain a corresponding IP address, or directly extracting the source IP address from the IP layer as an analyzed IP address of the domain name of the source host;

the protocol stack submits the message to the application.

According to an embodiment of the method for receiving a message in a TCP/DN/IP network compatible TCP/IP network of the present invention, the pseudo address pool is composed of pseudo IP addresses that are not really used for network access, the entry of the address translation table includes the pseudo IP addresses, domain names and resolved IP addresses, and the correct domain name of the target host is provided when the message is extended from TCP/IP encapsulation to TCP/DN/DP encapsulation by using the address translation table and its pseudo IP addresses.

According to an embodiment of the method for receiving a message in a TCP/DN/IP network compatible TCP/IP network of the present invention, the address translation table deletes entries that are no longer used based on a time aging mechanism.

Compared with the prior art, the invention has the following beneficial effects: the invention transparently converts the IP message sent by the application program into the message in the TCP/DN/IP encapsulation format by designing the encapsulation/decapsulation flow different from the OSI network model and utilizing the technology of a pseudo address and an address translation table, thereby being capable of normally forwarding between different IP domains defined by the TCP/DN/IP protocol and normally restoring at the receiving end. Also, the conversion mechanism applicable to ALG is considered. The method for transparent bidirectional conversion between the TCP/IP protocol and the TCP/DN/IP protocol can ensure that the TCP/DN/IP protocol is completely and compatibly applied to bear the traditional network application program realized based on the TCP/IP and ensure that the upgrading process becomes extremely smooth.

Drawings

Figure 1 shows a standard TCP/IP protocol stack encapsulation flow diagram.

FIGS. 2A and 2B show an internal flow diagram of standard TCP/DN/IP protocol stack functions.

FIG. 3 shows a standard TCP/DN/IP protocol stack encapsulation flow diagram.

FIG. 4 shows a compatible TCP/DN/IP protocol stack encapsulation flow diagram.

Fig. 5A and 5B show internal flow diagrams of compatible TCP/DN/IP protocol stack functions.

Fig. 6 shows a flow chart of a preferred embodiment of the message sending method in a TCP/DN/IP network compatible TCP/IP network of the present invention.

Fig. 7 shows a flow chart of a preferred embodiment of the message receiving method in a TCP/DN/IP network compatible TCP/IP network of the present invention.

FIG. 8 shows a schematic diagram of a client TCP/IP application accessing a TCP/DN/IP host.

FIG. 9 shows a schematic diagram of a server side TCP/IP application receiving TCP/DN/IP host access.

FIG. 10 shows a schematic diagram of a TCP/DN/IP protocol stack.

Detailed Description

The above features and advantages of the present disclosure will be better understood upon reading the detailed description of embodiments of the disclosure in conjunction with the following drawings. In the drawings, components are not necessarily drawn to scale, and components having similar relative characteristics or features may have the same or similar reference numerals.

Embodiment of conversion method for TCP/DN/IP network compatible with TCP/IP network

Fig. 10 shows a schematic diagram of a TCP/DN/IP protocol stack, and fig. 3 shows a standard TCP/DN/IP protocol stack encapsulation flow diagram. As shown in fig. 3, when assembling the domain name layer header of the TCP/DN/IP packet, the host needs to fill in the domain name of the target host, so when designing the protocol stack sending function, the application needs to directly transmit the domain name, the transport layer protocol type, and the user data of the target host as parameters. After the packet is passed from the domain name network layer to the IP network layer, the domain name still needs to be resolved into an IP address so as to fill in the destination address field of the IP header. At this time, the network protocol stack of the operating system should directly call the function of the gethostbyname class to resolve the domain name into an IP address at the IP network layer.

In order to be compatible with the traditional transmission mode of the network application program based on the TCP/IP, the invention designs a compatible TCP/DN/IP protocol stack encapsulation flow shown in figure 4. As shown in fig. 4, the application still operates in the conventional manner, i.e., it resolves the domain name of the target host to an IP address by itself through DNS, and then passes the IP address as a parameter to the function that sends the message. After the IP network layer finishes encapsulation and before the message is sent to the link layer, the message is intercepted, and a domain name layer header and a UDP header required by a TCP/DN/IP protocol are inserted between the IP header and Data (namely the TCP/UDP header + Data in figure 4), so that the format of the message meets the definition of the TCP/DN/IP.

However, the domain name and the IP address do not correspond one-to-one. A domain name may resolve to multiple IP addresses, and an IP address may correspond to multiple domain names. When deciding the destination domain name based on the destination IP address in the IP header, we need to know exactly what domain name to insert. Therefore, the present invention designs a method for utilizing the dummy address pool, which is described in detail below.

The conversion method of the compatible TCP/IP network of the TCP/DN/IP network of the invention mainly comprises two procedures: the process of sending the message by the application program and the process of receiving the message by the application program. The flow of sending a message by an application is shown in fig. 6, and the flow of receiving a message by an application is shown in fig. 7.

Referring to fig. 6, the following is a detailed description of the process of sending a message by an application.

And the application program calls a system protocol stack to analyze the domain name of the target host as the IP address through the DNS, and the protocol stack analyzes and checks the analysis result. If the returned result indicates that the target host is not upgraded or is upgraded but is in the same IP domain as the host in which the application program is located, returning the IP address obtained by analysis to the application program, otherwise, inquiring a corresponding table entry in an address translation table according to the domain name of the target host and the IP address obtained by analysis, if the corresponding table entry does not exist, firstly allocating an unused pseudo IP address from a pseudo address pool, newly adding an entry comprising the domain name of the target host, the IP address obtained by analysis and the newly allocated pseudo IP address in the address translation table, and returning the pseudo IP address to the application program as the DNS inquiry result.

When an application program sends a message, a protocol stack compares a target host IP address in an IP header with a pseudo IP address column in an address translation table, if no corresponding table entry exists, the message is encapsulated by using a TCP/IP protocol stack, if a corresponding table entry exists, a target host domain name and an analyzed IP address of a target host are taken out from the corresponding table entry of the address translation table, a domain name layer header is added to the message and is filled in the target host domain name, a UDP header is added, and the target address of the IP header is changed into the analyzed IP address of the target host domain name. And finally, sending the messages of the bottom layer.

As shown in fig. 5A, inside the compatible TCP/DN/IP protocol stack function, a pseudo address pool is created in advance, the pseudo address pool being composed of IP addresses that are not actually accessed. It is proposed to use 127.0.0.0/8 to remove 127.0.0.1 and multicast addresses (224.0.0.0-239.255.255.255) to remove a limited number of allocated addresses as available pseudo addresses (currently roughly 272M total address space) to put in the pool. A translation table is created in the pseudo address pool, containing three columns of "pseudo IP address", "domain name" and "resolved address".

At the beginning this table is empty:

pseudo IP address	Domain name	Resolving addresses
			……	……	……

The operating system's domain name resolution function (which in most TCP/IP stack implementations should be the gethostbyname () function) is intercepted and replaced with our own function (i.e., the user calls the domain name resolution function of the system to the function that we use to replace).

The application program first calls a function for resolving the domain name to obtain the IP address corresponding to the domain name of the target host, and at this time, the substitute function of the application program is called. The substitution function first performs a standard DNS query to obtain the IP and possibly an alias for the target domain name. Because the TCP/DN/IP scheme is designed to use aliases in the DNs system to indicate the upgrade status of a host, we can now determine whether the target host has been upgraded by checking whether there are aliases in the specified format, and with which protocol stack to access.

If the target host is not upgraded, the target host must be accessed by using a TCP/IP protocol stack; if the target host is in the same IP domain as the source host although upgraded, then either a TCP/IP protocol stack or a TCP/DN/IP protocol stack may be used. The use of TCP/IP is proposed to improve efficiency; other cases must use the TCP/DN/IP protocol stack.

Examples are as follows.

For example, cn and us are two IP domains, and there are several cases:

1) cn to access 1-1-1-1.cn

At this point, the DNS query is not required. When finding that 1-1-1-1.cn is completely the same as the suffix of the domain name of the host, the cn can judge that the target host and the host are in the same IP domain; meanwhile, the host part is the deformation of the IP address and can directly resolve the IP address (meeting the naming convention of TCP/DN/IP to DNS). The target host can be judged to support TCP/DN/IP and be in the same IP domain with the source host.

In this case, either TCP/IP or TCP/DN/IP may be used.

2) Cn is to access the same IP domain host foo.cn (assuming its IP is 1.1.1.1)

At this point the DNS must be queried to obtain the IP address. If foo.cn is not upgraded, DNS will directly return the IP address 1.1.1.1 corresponding to foo.cn. Because no alias prefixed by dnip appears in the middle, host.cn now knows that foo.cn does not support TCP/DN/IP. At this point the TCP/IP protocol stack must be used.

If the target host has been upgraded to support TCP/DN/IP, the DNs returns the mapping of foo.cn to the alias dnip.foo.cn (a prefix of dnip is a flag, and hereinafter does not require necessarily be foo.cn), and the mapping of dnip.foo.cn to IP 1.1.1.1. Cn may determine that fo.cn supports TCP/DN/IP and is in the same IP domain as the source host. In this case, either TCP/IP or TCP/DN/IP may be used.

3) Cn to access other IP domain hosts such as foo. us, 1-1-1-1.us, etc

At this point the DNS must be queried to obtain the IP address. According to the TCP/DN/IP forwarding rule, the DNs within the cn domain returns the IP address of the domain name router (possibly mapped: foo. us → dnip. router. cn → a.b.c.d, 1-1-1.us → dnip. router. cn → a.b.c.d), host.cn knows that the target host is in another IP domain and supports TCP/DN/IP.

At this point the TCP/DN/IP protocol must be used.

If the TCP/IP is decided to be used, directly returning the real IP; if the decision is made to use TCP/DN/IP, the following is performed:

1. and searching a pseudo address which is not used in the pseudo address pool, establishing a mapping relation between the pseudo address and a domain name and an IP (Internet protocol) returned by the DNS (domain name system) and recording the mapping relation in an address translation table. If a domain name returns multiple IP addresses, they are added separately to the translation table. Examples are as follows:

in the above table we have selected 127.0.0.2 starting a series of IPs as pseudo-addresses. Assuming multiple IPs are returned by DNS query www.sina.com.cn, they are added one by one to the table; also, it is assumed that bbs.aaa.com and www.aaa.com correspond to the same IP (100.100.100.100), and are also added to the table.

If the table has entries corresponding to the domain name and the IP, then no duplicate addition is required.

The conversion table is provided with a pseudo address as a main key, and the domain name and the IP are allowed to be repeated, but the domain name and the IP are not allowed to be repeated.

2. The pseudo address is returned to the application calling the function as the return value of our own alternative domain name resolution function.

After the application program obtains the IP returned by the domain name resolution function, it initiates a network communication process, as shown in fig. 5B:

(1) if the target IP of the message is not a pseudo address, the fact that the domain name resolution function returns the real IP is shown, namely, the user decides to use TCP/IP to access the target host. We do not need to manage such messages and pass through the messages.

(2) If the application is trying to access a host that needs to be accessed using the TCP/DN/IP protocol, then the IP it gets must be the pseudo address we have previously provided. At this point we should see that the IP destination address of the message is exactly the pseudo address we have provided.

(3) At this time, the table entry corresponding to the pseudo address is searched in the conversion table, the analytic IP and the target domain name are extracted from the table entry, the target address in the IP header of the message is replaced by the analytic IP, a UDP header and a domain name header required by a TCP/DN/IP protocol are inserted behind the IP header, and the domain name of the target host is filled in the target host field of the domain name header.

(4) After the above operation is completed, the message is still a legal IP message. And the message is delivered to the bottom layer of a system protocol stack for continuous processing. Because a new field is inserted, the length of the message is increased, and the message exceeding the MTU needs to be fragmented according to the specification of the IP when necessary.

And carrying out message sending of the bottom layer.

Referring to fig. 7, the following is a detailed description of the process of receiving a message by an application.

The application receives messages from the bottom layer.

In the protocol stack at the receiving end, the message is transmitted along the bottom-up path. The message is intercepted when it is passed up from the link layer (MAC sublayer + LLC sublayer) to the IP layer.

The protocol stack judges whether the message is TCP/DN/IP encapsulation, if not, the standard IP message is directly received. If the source host IP is TCP/DN/IP encapsulation, the domain name of the source host is extracted from the domain name layer, and the corresponding IP is analyzed through a gethostbyname () function or the IP of the source host is directly extracted from the IP layer.

If the message is a TCP/DN/IP encapsulation, the UDP header and the domain name header contained in the TCP/DN/IP protocol are removed, and the message is recovered to be a standard TCP/IP encapsulation message (if the message is a TCP/UDP message, the checksum of the dummy header is required to be recalculated). However, if only doing this, when the application responds to the message, the host will not know whether the opposite side supports TCP/DN/IP, nor whether the source IP address is the real address of the opposite side host or the interface address of the domain name router, and therefore will not be able to convert the response message into a proper encapsulation form to be sent back to the opposite side host.

Therefore, after obtaining the source IP, we search the domain name of the source host in the address translation table, if there is a corresponding entry, take out the corresponding pseudo IP address, and if there is no corresponding entry, add a new entry in the address translation table, the contents include: newly allocating an unused pseudo IP address from the pseudo address pool, extracting a domain name of a source host from a domain name layer, and correspondingly resolving the IP address;

and then removing TCP/DN/IP encapsulation, restoring the received message into a standard IP message and changing the IP source address of the message into the newly-allocated pseudo IP address.

The protocol stack submits the message to the application.

Some protocols such as FTP, h.323, etc. carry IP addresses in the application layer, and if the addresses carried by the application layer are not simultaneously converted during message conversion, the opposite end host cannot normally establish a reverse connection. The conversion includes two links: a first link and a second link.

In the first step, before the message is sent out by the host, the IP address in the application layer needs to be converted into a domain name address. The conversion mode is similar to that of the IPv 4-based NAT protocol, but the difference lies in that the invention requires to convert the IP address into the domain name, the lengths or types of the two are not guaranteed to be consistent, and the message format needs to be properly adjusted to ensure that the receiving end can correctly restore the address information of the application layer. The invention does not limit the adjusting form, only needs to be able to correctly transmit the domain name of the source host to the opposite terminal host, and the opposite terminal host can be correctly restored to the standard format.

In the second step, after the message reaches the target host, the domain name address after conversion is carried in the application layer, and the application program can only accept the address in the IP format. At this point, the domain name still needs to be converted back to IP.

At this time, an unused pseudo address can be found and a corresponding relationship with the domain name in the application layer is established and then filled in the conversion table (but there is no corresponding IP address). When an application receives an IP address in the application layer and attempts to initiate a connection to this address, it will send out an IP message that the target IP is this pseudo address. At the moment, the system reversely checks the domain name of the target host according to the pseudo address, resolves the real IP through the DNS, and encapsulates the correct TCP/DN/IP message according to the two.

Preferably, the system runtime translation tables are continually increased, and a mechanism based on time aging may be introduced to remove unused mapping entries.

Embodiments of a method for messaging in a TCP/DN/IP network compatible TCP/IP network

Referring to fig. 6, the flow of sending a message by an application is described in detail.

At the beginning this table is empty:

pseudo IP address	Domain name	Resolving addresses
			……	……	……

Examples are as follows.

For example, cn and us are two IP domains, and there are several cases:

1) cn to access 1-1-1-1.cn

In this case, either TCP/IP or TCP/DN/IP may be used.

2) Cn is to access the same IP domain host foo.cn (assuming its IP is 1.1.1.1)

3) Cn to access other IP domain hosts such as foo. us, 1-1-1-1.us, etc

At this point the TCP/DN/IP protocol must be used.

pseudo address	Domain name	True address
			127.0.0.2	www.sina.com.cn	61.172.201.195
127.0.0.3	www.sina.com.cn	61.172.201.237
			127.0.0.4	www.sina.com.cn	61.172.201.239
127.0.0.5	www.sina.com.cn	61.172.201.194
			127.0.0.6	bbs.aaa.com	100.100.100.100
127.0.0.7	www.aaa.com	100.100.100.100
			……	……	……
127.255.255.254	-	-

(1) if the target IP of the message is not a pseudo address, it indicates that the domain name resolution function returns a real IP, i.e. the target host is not upgraded or is an upgraded host in the same IP domain, and we still adopt TCP/IP encapsulation to obtain higher efficiency. We do not need to manage such messages and pass through the messages.

(2) If an application has to access the target host using TCP/DN/IP, then the IP it gets must be the pseudo address we have previously provided. At this point we should see that the IP destination address of the message is exactly the pseudo address we have provided.

And finally, sending the messages of the bottom layer.

Message receiving method in TCP/DN/IP network compatible TCP/IP network

The application receives messages from the bottom layer.

The protocol stack judges whether the message is TCP/DN/IP encapsulation, if not, the standard IP message is directly received, if the message is TCP/DN/IP encapsulation, the domain name of the source host computer is extracted from the domain name layer, and then the corresponding IP is analyzed through a gethostbyname () function or the IP of the source host computer is directly extracted from the IP layer.

then removing the package of TCP/DN/IP, reducing the received message into a standard IP message and changing the IP source address of the message into the newly allocated pseudo IP address.

The protocol stack submits the message to the application.

Example of a flow for a client TCP/IP application to access a TCP/DN/IP host

As shown in fig. 8, there is a host in the chinese country domain with an IP address of 100.1.1.1, and there are 2 TCP/IP-based applications accessing server1.com (2.1.1.1) and server2.com (2.1.1.2) in the global domain, respectively. A domain name router CN DNR on the domain boundary is responsible for forwarding between the global domain and the chinese country domain, and has an IP address of 1.1.1.1 in the global domain and 200.1.1.1 in the chinese country domain.

The content of the message in each link is as follows:

cn, the contents of the translation table on host are as follows:

pseudo address	Domain name	True IP
			127.0.0.2	server1.com	100.1.1.1
127.0.0.3	server2.com	100.1.1.1

Example of a flow for a server TCP/IP application to receive TCP/DN/IP host access

Com, with an IP address of 2.2.2.2; there are 2 hosts host1.cn and host2.cn in the country domain of china, and IP addresses are 100.1.1.1 and 100.1.1.2, respectively. A domain name router CN DNR on the domain boundary is responsible for forwarding between the global domain and the chinese country domain, and has an IP address of 1.1.1.1 in the global domain and 200.1.1.1 in the chinese country domain.

Taking the example that host1.cn and host2.cn send messages to server.com, the key information of the host messages in each link in the network is as follows:

com at the same time, the contents of the translation table on server are as follows:

pseudo address	Domain name	True IP address
			127.0.0.2	host1.cn	1.1.1.1
127.0.0.3	host2.cn	1.1.1.1

While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance with one or more embodiments, occur in different orders and/or concurrently with other acts from that shown and described herein or not shown and described herein, as would be understood by one skilled in the art.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk (disk) and disc (disc), as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks (disks) usually reproduce data magnetically, while discs (discs) reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A conversion method for TCP/DN/IP network compatible with TCP/IP network, in which DN is the acronym of English Domain Name of Domain Name, includes the flow of sending message by application program and the flow of receiving message by application program, in which:

sending a message of a bottom layer; the process of receiving the message by the application program comprises the following steps:

the application program receives a message from the bottom layer;

if the package is TCP/DN/IP, then:

the protocol stack submits the message to the application.

2. The method of claim 1, wherein the pool of pseudo-addresses is comprised of pseudo-IP addresses that are not really used for network access, the entries of the address translation table include pseudo-IP addresses, domain names and resolved IP addresses, and the correct destination host domain name is provided when the packet is extended from TCP/IP encapsulation to TCP/DN/DP encapsulation using the address translation table and the pseudo-IP addresses.

3. The method according to claim 1, wherein if the message sent by the application program carries the IP address of the source host in the application layer, the message is converted into the domain name address of the source host before being sent out, wherein the format of the message is adjusted to ensure that the receiving end restores the address information of the application layer, and the domain name address in the application layer is converted back into the pseudo IP address by using the address conversion table after the message reaches the destination host.

4. A method for converting a TCP/DN/IP network compatible TCP/IP network according to claim 2, wherein the address translation table deletes entries that are no longer used based on a time aging mechanism.

5. A message sending method in a TCP/DN/IP network compatible with the TCP/IP network, wherein DN is the acronym of English Domain Name of a Domain Name, the method comprises the following steps:

the application program calls a system protocol stack to analyze a domain name of a target host as an IP address through a DNS, the protocol stack analyzes and checks an analysis result, if the returned result indicates that the target host is not updated or is updated but is in the same IP domain as the host in which the application program is positioned, the IP address obtained by analysis is returned to the application program, otherwise, a corresponding table entry is inquired in an address conversion table according to the domain name of the target host and the IP address obtained by analysis, if the corresponding table entry does not exist, an unused pseudo-IP address is firstly allocated from a pseudo-address pool, a table entry comprising the domain name of the target host, the IP address obtained by analysis and the newly allocated pseudo-IP address is newly added in the address conversion table, and the pseudo-IP address is returned to the application program as the result of DNS inquiry;

and carrying out message sending of the bottom layer.

6. The method according to claim 5, wherein the pool of pseudo addresses is composed of pseudo IP addresses that are not really used for network access, the entries of the address translation table include pseudo IP addresses, domain names and resolved IP addresses, and the correct destination host domain name is provided when the packet is extended from TCP/IP encapsulation to TCP/DN/DP encapsulation using the address translation table and its pseudo IP addresses.

7. The method of claim 6, wherein the address translation table deletes entries that are no longer used based on a time aging mechanism.

8. A message receiving method in a TCP/DN/IP network compatible with the TCP/IP network, wherein DN is the acronym of English Domain Name of a Domain Name, the method comprises the following steps:

the application program receives a message from the bottom layer;

if the package is TCP/DN/IP, then:

removing TCP/DN/IP encapsulation in the message, restoring the received message into a standard IP message and changing the source IP address into a corresponding newly allocated pseudo IP address; the protocol stack submits the message to the application.

9. The method of receiving a packet in a TCP/DN/IP network compatible TCP/IP network as claimed in claim 8, wherein the pool of pseudo addresses is comprised of pseudo IP addresses that are not really used for network access, the entries of the address translation table include pseudo IP addresses, domain names and resolved IP addresses, and the address translation table and its pseudo IP addresses are used to provide a correct destination host domain name when the packet is extended from TCP/IP encapsulation to TCP/DN/DP encapsulation.

10. The method of receiving a message in a TCP/DN/IP network compatible TCP/IP network as claimed in claim 9, wherein the address translation table deletes the entry that is no longer used based on a time aging mechanism.