JP4611319B2 - Network architecture - Google Patents

Description

  This application is Canadian Patent Application No. 2457909 filed on February 16, 2004, US Provisional Patent Application No. 60/544341 filed on February 17, 2004, filed April 20, 2004. Canadian Patent Application No. 2464274, Canadian Patent Application No. 2467063 filed on May 17, 2004, Canadian Patent Application No. 2471929 filed June 22, 2004, August 2004 Claimed priority based on Canadian Patent Application No. 2476928 filed on 16th and Canadian Patent Application No. 2479485 filed on 20th September 2004, the contents of all the above references are referenced Is incorporated herein by reference.

  The present invention relates generally to electronic devices, telecommunications devices, and computing devices that communicate with each other, and more particularly to a network architecture for them.

  Networked devices are now a vital aspect of our social infrastructure. The public switched telephone network ("PSTN") is perhaps the first example of a ubiquitous network of telecommunications devices that has changed the way people interact. Currently, mobile telephone networks, the Internet, local area networks (“LAN”), wide area networks (“WAN”), and voice over Internet protocol (“VOIP”) networks are widely deployed and continue to grow.

  Unfortunately, each of these devices needs to be able to reach each other to perform networking functions. The PSTN uses a telephone number system including a country code, an area code, a city code, and the like. At least in North America, the explosive growth of phones has extended the standard 10-digit number system. In the Internet, Internet Protocol Version 4 (“IPV4”) has spread the Internet Protocol (“IP”) address scheme for identifying points on the Internet, so that each device connected to the network is on the Internet. Has an address that makes the device reachable. Because at least in part, the length of the IPV4 address field is limited, IP addresses can only have a slight geographical relationship to their physical location. As a result, routers and routing tables have grown significantly throughout the Internet, increasing the complexity of traffic routing and increasing network latency. IPV6 provides a potential problem mitigation address, but the upgrade to IPV6 is not expected to make much progress.

  In very general terms, many prior art network architectures rely on routing devices to maintain device addresses and locations across the network. Such a routing device is essentially a traffic director that routes traffic along an appropriate path. Such an architecture becomes sluggish and inconvenient as the network grows.

  Various “routerless” network architectures have been proposed. Some of these architectures are called peer-to-peer networks and others are called ad hoc networks. In any case, these prior art architectures still tend to have drawbacks such as scalability and / or other limitations. One attempt to improve the network architecture is the ad hoc on demand distance vector (“AODV: Ad Hoc On Demand Distance Vector”). AODV is a reactive protocol that uses broadcast flooding to establish new connections or repair broken connections. AODV is available at http: // www. ietf. org / rfc / rfc3561. It is described in detail in the Internet Engineering Task Force (“IETF”) document obtained from txt. Although AODV has the advantage that nodes can be easily organized into an ad hoc network, one problem with AODV is that the maximum network size is severely limited.

  Another attempt to improve the network architecture is the “Destination Sequence Distance Vector” (“DSDV: Destination Sequenced Distance Vector”). DSDV is a proactive protocol that uses continuous flooding of update information to generate and maintain routes to and from all nodes in the network. A detailed description of DSDV can be found at http: // sitesee. ist. psu. edu / cache / papers / cs / 2258 / http: zSzzSzwww. srvloc. orgzSzcharliepzSzttzzSzsigcom94zSzpaper. pdf / perkins94highly. pdf, or http: // siteseeer. ist. psu. edu / perkins 94 highly. Found in html. DSDV has the advantage of providing loop-free routing, but has the disadvantage that it only works in small networks. In large networks, control traffic easily exceeds the available bandwidth.

  Another attempt to improve the network architecture is “optimized link state routing” (“OLSR”). OLSR is a proactive protocol that attempts to build knowledge about the network topology. A detailed description of OLSR can be found in the following IETF draft http: // hipercom. inria. fr / olsr / draft-ietf-manet-olsr-11. can be found at txt. OLSR has the advantage of being a more efficient link state protocol, but still cannot support larger networks.

  Another attempt to improve the network architecture is “shortest path first open” (“OSPF: Open Shortest Path First”). OSPF is a proactive link state protocol used by several Internet core routers. A detailed description of OSPF can be found at the following IETF draft http: // www. ietf. org / rfc / rfc1247. can be found at txt. OSPF allows the core Internet router to bypass failures, but there are limits to the size of the network that can be supported.

  Despite the differences between AODV, DSDV, OLSR, and OSPF, they all share some of the same issues, such as being difficult to scale beyond hundreds of nodes. This limitation occurs because the amount of control traffic required increases much more rapidly as the network grows. The required amount of control traffic will quickly exceed the network capacity.

  In general, prior art network architectures do not provide good scalability and do not provide the ability to allow low capacity devices to fully interact with larger networks, and in mobile environments, prior art architectures. Does not always provide seamless mobility.

  It is an object of the present invention to provide a novel system and method for networking that eliminates or mitigates at least one of the prior art difficulties identified above.

  A first aspect of the present invention provides a network including a plurality of nodes and a plurality of links interconnecting adjacent nodes of the nodes. Each of the nodes is operable to maintain information about each of the nodes present in the first partition of the node. The information includes first identification information indicating another node in the first section, and for reaching the other node corresponding to the first identification information for each first identification information. 2nd identification information showing the adjacent node which is a desirable step. Each of the nodes is operable to determine a neighboring node that is a desirable step for finding the node in a second partition of the node that is not included in the first partition.

  In a particular implementation of the first aspect, the determination is based on which of the neighboring nodes appears most frequently in each of the second identification information.

  In a particular implementation of the first aspect, each of the nodes is operable to exchange the information with its neighboring nodes.

  In a particular implementation of the first aspect, each link has a set of service characteristics such that any path between two of the nodes has a set of cumulative service characteristics, where The desired step is based on which of the paths has a desirable set of cumulative service characteristics.

  In a particular implementation of the first aspect, the service characteristics include at least one of bandwidth, latency, and bit error rate.

  In a particular implementation of the first aspect, the node is at least one of a computer, a phone, a sensor, and a personal digital assistant.

  In a particular implementation of the first aspect, the link is based on at least one of a wired connection and a wireless connection.

  In a particular implementation of the first aspect, a network core is formed between adjacent nodes that are determined to be desirable steps for reaching each other in the second partition.

  In a particular implementation of the first aspect, each node is operable to instruct other nodes between the core and the node to maintain information about the node.

  In a particular implementation of the first aspect, each node is operable to request information about the nodes that are in the second partition, each node being between the core and the node It is operable to make the request to the other node.

  One advantage of the present invention over the prior art is that the network architecture taught herein enables large scale self-organizing networks. In some embodiments, this feature is possible because, in practice, very few nodes in the network need have knowledge of the entire network. All nodes in the network have a collective knowledge of the entire network and are not aware of other nodes, but nodes that need to find such other nodes are in the network with relevant knowledge. By seeking such knowledge from other nodes, a means of finding those other nodes is provided. For these and other reasons, the present invention is a novel self-organizing network architecture that allows a much larger self-organizing network compared to prior art self-organizing network architectures. Accordingly, a second aspect of the present invention provides a self-organizing network that includes at least 2000 nodes interconnected by a plurality of links. A third aspect of the invention provides a self-organizing network that includes at least 5000 nodes interconnected by a plurality of links. A fourth aspect of the invention provides a self-organizing network that includes at least 10,000 nodes interconnected by a plurality of links. A fifth aspect of the invention provides a self-organizing network including at least 100,000 nodes interconnected by a plurality of links.

  The invention will now be described by way of example only with reference to the accompanying drawings.

  Referring now to FIG. 1, a network according to one embodiment of the present invention is indicated generally at 30. The network 30 includes a plurality of nodes N1, N2, and N3. Nodes N1, N2, and N3 are collectively referred to as node N and generically referred to as node N. This nomenclature is also used for the other elements described herein.

  The node N1 is connected to the node N2 via the first physical link L1. The node N2 is connected to the node N3 via the second link L2. Node N1 is an adjacent node of node N2, and similarly, node N2 is an adjacent node of node N1, because both nodes are connected by link L1. Further, the node N3 is an adjacent node of the node N2, and similarly, the node N2 is an adjacent node of the node N3 because both nodes are connected by the link L2. Accordingly, in this document, the term “neighboring node” (and variations thereof depending on the context) is used to indicate a node N that is connected to another node N by a single link L.

  Each node N is any type of computing device that is operable to communicate with another node N via a respective link L. Any type of computing device can be a personal computer (“PC”), laptop computer, personal digital assistant (“PDA”), voice over internet protocol (“VOIP”) landline telephone, cellular telephone, smart sensor Etc., or combinations thereof are contemplated. Each node N can be a different type of computing device.

  Each link L includes OC3, T1, Code Division Multiple Access (“CDMA”), Orthogonal Frequency Multiple Access (“OFDM”), Global System for Mobile Communications (“GSM”), Global Packet Relay Service (“GPRS”), Based on any type of communication link, including but not limited to Ethernet, 802.11 and its variants, Bluetooth, etc., or combinations or hybrids thereof, and may be wired or wireless.

  The type of computing device used to implement a particular node N, and the type of link L between them, is not limited in detail; generally speaking, each node N can be any adjacent node It should be understood here that it is operable to connect and communicate via N and the respective links L between them.

  Each node N maintains a network information database D configured to hold knowledge of at least some of the other nodes N in the network 30. Each database D is volatile in volatile storage (eg, random access memory (“RAM”)) and / or non-volatile storage (eg, hard disk drive) or volatile in the computing environment associated with that individual node N. Stored in a combination of volatile storage or non-volatile storage. The database D is used by each node N to find other nodes N in the network 30, so that the node N can send traffic to the other nodes N it finds and / or Used by each node N to share knowledge about other nodes N.

  Each database D is shown in FIG. 1 as an ellipse, indicated by the reference symbol D located in its individual node N, representing that node N has its own database D Yes. More specifically, database D1 is shown in node N1, database D2 is shown in node N2, and database D3 is shown in node N3. The size, complexity, and other overhead metrics that define the structure of each database D are selected such that the database D occupies only a portion of all the computing resources available at that individual node N. . Thus, the structure of database D is generally but not necessarily selected such that a significant portion of a node N's computing resources are freed to perform its normal computing tasks. Further details on such overhead metrics are described in more detail below.

However, in the exemplary network 30 of FIG. 1, it is assumed that all nodes N have substantially equal computing resources and all links L have substantially the same service characteristics. (The term “service characteristic” as applied herein to link L refers to any known quality of service, including bandwidth, latency, bit error rate, etc. that can be used to evaluate the quality of link L. ("QOS"), because the monetary cost of carrying traffic over one link may be different from the monetary cost of carrying traffic over another link. Can also include pricing). Accordingly, each database D is assumed to have substantially the same structure, and an example of such a structure is shown in Table I.

  Generally speaking, each database D provides a list of at least some of the nodes N in the network 30 (“other nodes N”) in addition to the node N holding the database D. To do. Each database D also ranks their other nodes N according to their importance within the network 30. Metrics reflecting importance may be the proximity of such other nodes N and / or what percentage of other nodes N will share and transmit traffic within the network 30 and / or Including, but not limited to, the proximity of a node N to a data flow towards another node N. Other metrics will occur to those skilled in the art. Some of them are described in more detail below. Each database D also identifies their other nodes N and neighboring nodes N that represent the best next steps to reach each other node N.

  Explaining Table I in more detail, the “rank” in column 1 of Table I indicates the number by which the value of each row of database D increases based on the number of other nodes N held in that database D. .

  “Node name” in column 2 of Table I identifies a particular other node N. Such node names can be based on any known or future network addressing scheme. Examples of known node addressing schemes include telephone numbers, or media access control (“MAC”) addresses, or Internet protocol (“IP”) addresses. Such an addressing scheme may be selected according to other factors that affect the design of network 30 and / or node N therein. However, it should be noted that in the addressing scheme of the present invention, the name of each node N is in the network as seen in other addressing schemes such as, for example, telephone numbers having an area code corresponding to a geographical location. It is not necessary to reflect the location of that node N. In order to simplify the description of the embodiments herein, the node names are identified according to reference numerals in the drawings. For example, if the node name entry under column 2 indicates “N1”, node N1 is identified.

  The “best neighbor” in column 3 of Table I indicates which of the neighbors N provides the best next step in the overall path to reach the other node N named in column 2 Indicates. [In this embodiment, the term “best neighbor” is used, but this term should not be construed in a limiting sense for all embodiments of the present invention; Otherwise, any desired criteria for determining the desired neighbor node can be selected. Thus, column 3 always identifies adjacent node N, but column 2 need not indicate adjacent node N. The entry in column 3 need not be the name of an adjacent node N that actually follows the same addressing scheme used in column 2, but can be any indicator of that particular adjacent node N. I want you to understand. However, to simplify the description of the embodiments herein, the entry in column 3 actually reflects the name of the adjacent node N.

When the network 30 is initialized (eg, when all nodes N are each connected to each other according to the topology shown in FIG. 1), the contents of each database D are owned by each database D It is empty except that it contains a “null” entry that identifies a particular node N. Thus, Table II shows how a “null” entry identifying node N1 is initially entered into database D1.

  Explaining Table II in more detail, the entry in row 1 of column 1 of Table II is given a null entry “0” and this information in database D1 is the node N1 that owns that database D1. Shows that it is about. The entry in row 2 of column 2 of Table II is “N1” that identifies node N1 by name. The entry in row 0 of column 3 of Table II is “N / A” indicating that this entry in Table II relates to the owning node of database D1, so that none of the best neighbors apply.

Similarly, Table III shows how a “null” entry identifying node N2 is initially entered in database D2.

Similarly, Table IV shows how a “null” entry identifying node N3 is initially entered in database D3.

  To enter the rest of each database D and hold their contents, the microprocessor at each node N executes a set of programming instructions. Those instructions are substantially the same at each node N. Referring now to FIG. 2, a flowchart representing a method for maintaining network knowledge in accordance with one embodiment of the present invention is shown generally at 200. In order to enter and maintain the contents of each database D, the method 200 can be implemented as a set of programming instructions that are executed on the microprocessor of each node N. For ease of explanation of the method, it is assumed that the method 200 is performed on each node N of the system 30 and maintains a database D corresponding to that node N. Accordingly, the following description of method 200 provides a further understanding of system 30 and its various components. (However, the system 30 and / or method 200 can be modified and need not be performed in the order shown in FIG. 2, and the system 30 and / or method 200 is described herein. It is not necessary to work as is, and it is understood that such modifications are within the scope of the present invention).

  Thus, before beginning the description of the method 200, the database D of each node N has only been entered according to Tables II, III, and IV, and each node N has been activated and is shown in FIG. It is assumed that they are physically connected to each other according to the structure of the links L.

  Method 200 begins initially at step 210 where the presence of a neighboring node is determined. Generally speaking, at step 210, each node N determines whether there is a new neighboring node N or whether an existing neighboring node N has terminated the connection with that node N. Thus, when step 210 is first executed by node N1, node N1 sends an initialization message to node N2 via link L1 to query the existence of node N2 and the resolution of link L1. Such an initialization message can be performed according to any known means depending on the type of protocol used to implement the link L1.

  Similarly, step 210 is also performed by node N2, so node N2 sends a network initialization signal to node N1 via link L1 to query the presence of node N1. Further, the node N2 sends a network initialization signal to the node N3 via the link L2 in order to inquire about the existence of the node N3.

  Finally, step 210 is also performed by node N3, so node N3 sends a network initialization signal to node N2 via link L2 to query the presence of node N2.

  Referring now to FIG. 3, this initial execution of step 210 by each node N is represented by showing a plurality of initialization messages IM sent in accordance with the above description. Specifically, the initialization message IM1-2 is transmitted from the node N1 to the node N2, the initialization message IM3-2 is transmitted from the node N3 to the node N2, and the initialization message IM2-3 is transmitted from the node N2. An initialization message IM2-1 is transmitted from the node N2 to the node N1. In this embodiment, the initialization message IM does not exchange node knowledge because it simplifies the initialization message IM and allows the node knowledge of node N to be spread to all nodes N in substantially the same way. . Since the processing and memory characteristics of node N are related to the node's ability to retain network knowledge, this initialization message IM can include such characteristics. Such processing and memory characteristics may include node N's memory, etc. dedicated to holding network knowledge. However, in this embodiment, the node name N itself is not exchanged as part of the initialization message IM.

  As a result of finding the neighboring node using the initialization message IM, each node N now knows its neighboring node N and therefore uses its neighboring database D to enter its individual database D. And the position to start holding.

  Thus, referring again to FIG. 2, method 200 proceeds from step 210 to step 220, where network knowledge is exchanged between neighboring nodes N identified in step 210. Each node N can now utilize the adjacency database D in order to gain more knowledge about the network 30.

  Referring now to FIG. 4, the initial execution of step 220 by each node N is represented by showing a set of bidirectional knowledge exchange messages KEM. Knowledge exchange between node N1 and node N2 is shown as knowledge exchange KEM message 1-2, and knowledge exchange between node N2 and node N3 is shown as knowledge exchange message KEM2-3.

Referring back to FIG. 2, the method 200 then proceeds from step 220 to step 230 where the local knowledge is updated as a result of the information exchange at step 220. As a result of exchanging message KEM, databases D1, D2, and D3 can be updated to reflect information about neighboring node N, as shown in Tables V, VI, and VII, respectively. Thus, Table V shows how database D1 is entered after the initial execution of step 230 by node N1.

  Explaining Table V in more detail, row 0 remains the same as in Table II. However, now that row 1 has been entered, node N1 now has knowledge of the node named node N2, and node N2 is the best neighbor that allows it to reach node N2. Show.

Thus, similarly, Table VI shows how database D2 is entered after the initial execution of step 230 by node N2.

  Explaining Table VI in more detail, row 0 remains the same as in Table III. However, now that row 1 has been entered, node N2 now has knowledge of the node named node N1, and that node N1 is the best neighbor that allows it to reach node N1. Show. Furthermore, now that row 2 has been entered, node N2 now has knowledge of a node named node N3, and that node N3 is the best neighbor that allows it to reach node N3. Show. Note that node N1 is given rank “1” and node N3 is given rank “2”. In this example, there is no metric to actually choose which one to rank higher, so such ranking is purely expedient. However, the rankings given by more complex grounds are explained in more detail below.

Thus, similarly, Table VII shows how database D3 is entered after the initial execution of step 230 by node N3.

  Explaining Table VII in more detail, row 0 remains the same as in Table IV. However, now that row 1 has been entered, node N3 now has knowledge of the node named node N2, and node N2 is the best neighbor that allows it to reach node N2. Show.

  The contents of Tables V, VI, and VII are shown as a knowledge path K represented by the dotted line in FIG. Knowledge path K1-2 corresponds to row 1 of table V and indicates that node N1 has knowledge of node N2, knowledge path K2-1 corresponds to row 1 of table VI and node N2 Indicates that the node has knowledge of the node N1. Similarly, the knowledge path K2-3 corresponds to row 2 of Table VI, and indicates that the node N2 has knowledge of the node N3. Path K3-2 corresponds to row 1 of Table VII and indicates that node N3 has knowledge of node N2.

  If a knowledge path exists between the source node N and the destination node N, payload traffic generated at the source node N and destined for the destination node N is now actually delivered to the node N according to the knowledge path K Can do. Such delivery of payload traffic may be performed via the best neighbor routing shown in column 3 as long as network knowledge about the destination node N is entered in column 2 of database D of source node N. it can.

  (As used herein, “payload traffic” or “payload” refers to any data generated by an application running on an originating node N and addressed to a destination node N. For example, If it is a computer, the payload traffic can include emails, web pages, application files, printer files, audio files, video files, etc. If node N is a phone, the payload traffic can include voice transmission. Other types of payload data will occur to those skilled in the art.

  More specifically, since node N1 and node N2 have knowledge of each other, they can now exchange payload traffic. Since the node N2 and the node N3 also have knowledge of each other, payload traffic can be exchanged. However, at this point, the node N1 and the node N3 do not have knowledge of each other and therefore cannot exchange payload traffic.

  Since the method 200 has been completely executed once so far, the method 200 returns from the step 230 to the step 210 and starts a new second time. Returning to step 210 again, the presence of an adjacent node is determined. During the second exemplary cycle of method 200, it is assumed that no new nodes N are added to network 30 and existing nodes N are not deleted. Accordingly, since no change has occurred, nothing is done in step 210 and method 200 proceeds from step 210 to step 220.

  Continuing with this example and referring again to FIG. 2, method 200 again proceeds from step 210 to step 220, where additional network knowledge is exchanged between neighboring nodes N. Once again, each node N can utilize the neighbor database D to gain more knowledge about the network 30.

  Referring now to FIG. 6, the second execution of step 220 by each node N is once again represented by a bidirectional knowledge exchange message KEM. Knowledge exchange between node N1 and node N2 is shown as knowledge exchange KEM message 1-2, and knowledge exchange between node N2 and node N3 is shown as knowledge exchange message KEM2-3.

Referring back to FIG. 2, method 200 then proceeds a second time from step 220 to step 230, where local knowledge is updated as a result of the information exchange at step 220. As a result of exchanging messages KEM, databases D1, D2, and D3 can be updated to reflect information about neighboring node N, as shown in Tables VIII, IX, and X, respectively. Table VIII shows how the database D1 has been entered after the second execution of step 230 by the node N1.

  Explaining Table VIII in more detail, row 0 and row 1 remain the same as those in Table V. However, now that row 2 has been entered, node N1 now has knowledge of a node named node N3, and that node N2 is the best neighbor that allows it to reach node N3. Show.

Similarly, Table IX shows how database D2 is entered after the second execution of step 230 by node N2.

  Explaining Table IX in more detail, row 0, row 1 and row 2 remain the same as in Table VI, as it will be recognized by node N2 by exchanging messages with neighboring node N. This is because the new node N is not present in the network 30.

Similarly, Table X shows how database D3 is entered after the second execution of step 230 by node N3.

  Explaining Table X in more detail, row 0 and row 1 remain the same as those in Table VII. However, now that row 2 has been entered, node N3 now has knowledge of the node named node N1, and that node N2 is the best neighbor that allows it to reach node N1. Show.

  The contents of Tables VIII, IX, and X are shown as a knowledge path K represented by the dotted line in FIG. In FIG. 7 (as previously shown in FIG. 5), knowledge path K1-2 indicates that node N1 has knowledge of node N2, and knowledge path K2-1 indicates that node N2 is node N2. Similarly, knowledge path K2-3 indicates that node N2 has knowledge of node N3, and knowledge path K3-2 indicates that node N3 is connected to node N2. It shows that you have knowledge of. However, FIG. 7 now also includes two additional knowledge paths, knowledge path K1-3 shows that node N1 now has knowledge of node N3, and likewise knowledge path K3. -1 indicates that node N3 now has knowledge of node N1.

  If a knowledge path exists between the source node N and the destination node N, payload traffic generated at the source node N and destined for the destination node N is now actually delivered to the node N according to the knowledge path K Can do. Such delivery of payload traffic may be performed via the best neighbor routing shown in column 3 as long as network knowledge about the destination node N is entered in column 2 of database D of source node N. it can. Therefore, more specifically, since all nodes N have knowledge of each other, now all nodes N can exchange payload traffic. Of particular note, after this execution of method 200, node N1 and node N3 may send payload traffic to each other via node N2 as a step between both nodes.

  Since the method 200 has been completely executed twice so far, it then returns from step 230 to step 210 and starts a new time. Prior to the execution of the third exemplary cycle of method 200, it is assumed that node N3 is removed from network 30 due to the failure of link L2, as shown in FIG. Returning to step 210 again, the presence of an adjacent node is determined. In this third time, during the exchange of the initialization message IM, the nodes N2 and N3 determine that they are no longer adjacent to each other. At step 220, knowledge is exchanged with neighboring nodes based on the neighboring nodes whose existence was confirmed at step 210. Finally, at step 230, local knowledge is updated based on the exchange.

After step 230, as shown in FIG. 8, the result remains the same for database D1 and retains the contents shown in Table VIII, since the loss of node N3 is the result of database D1. This is because the method 200 has been cycled insufficiently to propagate to However, the database D2 is now updated according to Table XI.

  Database D3 is also updated to reflect the initial data shown in Table IV. This is illustrated in FIG. 8, where the existing node N is not removed. Accordingly, since no change has occurred, nothing is done in step 210 and method 200 proceeds from step 210 to step 220.

  The contents of database D after this third execution of method 200 are reflected in knowledge path K shown in FIG.

  During the fourth execution of method 200, the loss of node N3 finally propagates to node N1, so that knowledge path K is as shown in FIG.

  (Those skilled in the art will appreciate that the above description is a simplified description for purposes of explanation and, if implemented, may introduce a trivial loop. To address this, “Poison reverse” can be introduced to remove trivial loops that are introduced into any network when a node is removed, which is described in more detail below. For further reduction, a delay is introduced when node knowledge spreads, while node knowledge deletion can be performed with “zero” delay (eg, substantially immediately). If the distance from the data flow (explained) reaches a certain limit, the node will have knowledge about that particular node that is still valid knowledge about that node. Even, a more detailed description of the notified. Node removal to the adjacent node to be deleted, further provided below).

  It should be understood here that the teachings herein are applicable to networks that are more complex than network 30. For example, referring now to FIG. 10, a slightly more complex network according to another embodiment of the present invention is indicated generally at 30a. The network 30a includes substantially the same elements as the network 30, and similar elements are given similar reference signs except that they are suffixed with "a". More specifically, the network 30a includes more nodes Na and links La, but the basic structure of those nodes Na and links La is substantially the same as their counterparts of the system 30. However, for the sake of simplicity, the network 30a is shown without a specific table indicating the contents of the database Da.

  Network 30a includes nodes N1a, N2a, and N3a that are connected via links L1a and L2a, as are the individual corresponding nodes N1, N2, and N3 of network 30. In this example, the network 30a has made two complete executions of the method 200, so it is initially assumed that the database Da is in the same state as shown for the network 30 of FIG. However, in contrast to the network 30, it is also assumed that the network 30a includes a fourth node N4a that is not initially connected to any other node Na.

Referring now to FIG. 11, the node N4a forms the link L3a spanned between the node N4a and the node N2a and the link L4a spanned between the node N4a and the node N3a, thereby remaining the network 30a. Assume that you participate in the part. After the method 200 has been repeated a sufficient number of times by each node Na, an additional knowledge path K (as shown in FIG. 11) is formed according to the update of the database Da as summarized in Table XII. .

  Payload traffic generated at the source node Na and destined for the destination node Na can now actually be delivered according to the knowledge path Ka. For example, suppose node N4a wants to send payload traffic to node N1a. Using the information in Table XII, it can be seen that traffic is routed from node N4a through node N2a to node N1a. This traffic path P is shown in FIG. 12, and FIG. 12 shows the network 30a in the same state as FIG. 11, but the knowledge path Ka is deleted so that the traffic path P can be seen more clearly. Yes.

  At this point, various nodes can reach other nodes via different paths, but it can be seen that certain preferred paths have been identified. In these embodiments, so far it has been assumed that all links L and La have substantially the same service characteristics, so such a preferred route has been chosen. For example, in FIGS. 11 and 12 corresponding to Table XII, the node N4a reaches the node N1a via the node N2a. This is reflected in column 12 of row 4 of Table XII, and node N2a is reflected as the best next step for reaching node N1a from node N4a. However, although not preferred in the example shown in Table XII, it is also possible that the payload traffic is physically delivered along a route that is finally delivered from the node N4a to the node N1a through the node N3a and the node N2a. This route is a route used when the link L3a does not exist.

However, in another embodiment, the service characteristics of each link can be different, and each node's database selects such service characteristics when selecting the best neighbor as the best next step to route payload traffic. Consider the knowledge of. For example, referring now to FIG. 13, another network according to another embodiment of the present invention is indicated generally at 30b. The network 30b is substantially the same as the network 30a, and similar elements are given the same reference numbers except that they are suffixed with "b". More specifically, the network 30b includes a link Lb, which follows the same path as the link La of the network 30a. The network 30b includes four nodes Nb, which are substantially the same as the node Na of the network 30a. However, in the network 30b, each link Lb has a different service characteristic, and in the network 30a, each link La has the same service characteristic. Table XIII shows an exemplary set of service characteristics for each link Lb.

  To explain Table XIII in more detail, column 1 identifies the particular link Lb in question. Column 2 identifies the bandwidth of link Lb identified in the same row. Column 3 specifies the monetary cost for transmitting traffic over a particular link Lb in cents per kilobyte. (It should be understood here that Table XIII can also include any other desired service characteristics, such as bit error rate, latency, etc.). Thus, information about each link Lb can be part of each database Db, using method 200 or a suitable variant thereof in much the same way that node knowledge is propagated through network 30b. And can be propagated through the network 30b.

  The database Db corresponding to each node Nb knows the details of each link Lb to which they are directly connected. For example, node N4b knows details about links L3b and L4b as shown in Table XIII. Furthermore, the node N3b knows details about the links L4b and L2b. In this embodiment, each node Nb only knows about itself and the link Lb it has to connect directly to the node Nb. However, each node Nb does not need to know anything about the overall network topology.

  However, if the database at one end of the route has knowledge about the node at the other end of the route, the database Db of each node Nb corresponding to each node Nb at each end of the route will link to define the route. Learn about the cumulative service characteristics associated with Lb. Thus, once the node N4b knows about the node N1b, the node N4b also knows about the cumulative service characteristics (and hence the accumulated “cost”) of all the links Lb between the node N4b and the node N1b.

  Thus, once a particular node Nb has information about the characteristics of a particular link Lb, that node Nb will use such information to determine the “best neighbor” as the best next step to route traffic. Can be used. For example, in Table XIII, it can be seen that the bandwidth of link L3b is only 0.5 megabits / second, while the bandwidth of link L4b and link L2b are both 10 megabits / second. Accordingly, payload traffic transmitted from the node N4b to the node N2b is delivered to the node N2b much faster when transmitted via the node N3b than directly transmitted via the link L3b.

Thus, using Table XIII, node N4b can determine that node N3b is the best next step to reach node N2b and node N1b if the delivery rate of payload traffic is a priority. Therefore, Table XIV shows what happens to part of database Db if node N4b makes such a determination (assuming that the information in Table XIII is not shown in Table XIV).

  Furthermore, FIG. 13 shows a path Pb of payload traffic for traffic transmitted from the node N4b to the node N1b based on the contents of the database D4b shown in Table XIV. In FIG. 13, the route Pb does not travel through the link L3b, but instead travels through the link L4b and the link L2b. It should be understood here that a number of complex criteria can be utilized when determining the best neighbor to route traffic to. Thus, Table XIV can be entered to optimize the service characteristics of link Lb for bandwidth, cost, bit error rate, and the like.

  Of course, if the best neighboring node is selected based on the best next step with the lowest monetary cost and table bandwidth is completely ignored, Table XIV will change. Referring again to Table XIII, since link L3b is financially less expensive than link L4b in this case, node N4b selects node N2b as the best next step to reach node N2b and node N1b, and therefore Database D4b is the same as database D4a in Table XII.

  The best next step can be based on a set of complex criteria that evaluate each link, for example, the overall rating of link Lb is determined by combining column 2 and column 3 of Table XIII, and bandwidth and money It should be made clear here that a rating of a service characteristic that is a combination of both cost-effective can be provided for a particular link.

  It should be emphasized again that the teachings herein are applicable to networks that are more complex than networks 30, 30a, and 30b. For example, referring now to FIG. 14, a more complex network according to another embodiment of the present invention is indicated generally at 30c. Network 30c includes elements of the same type as networks 30, 30a, and 30b, and similar elements are given similar reference signs except that they are suffixed with "c". It should be noted that in this embodiment, all links Lc are assumed to have substantially the same length and substantially the same service characteristics, but in other embodiments, link Lc is similar to link Lb. Can have different lengths and service characteristics. The network 30c includes more nodes Nc and links Lc, but for the sake of simplicity, the network 30c is shown without a specific table showing the contents of the database Dc.

  However, in contrast to the networks 30, 30a and 30b, in the network 30c, the database Dc has a limited number of rows because it places an upper limit on the memory resources of each node Nc consumed by the individual database Dc. It is assumed that there is no. Accordingly, in this network 30c, each node does not hold knowledge about the entire network 30c, but holds knowledge of only a part of the network 30c. (If the teachings herein apply to a network of a scale where knowledge of the entire network consumes the entire computing resource of a given node unrealistically, such a configuration is actually Is preferable). For ease of explanation, it is assumed that each database Dc can store 11 lines of information. The first row is the null row described above in connection with Table II and identifies the node Nc to which the database Dc belongs. The remaining nine rows allow database Dc to hold knowledge about the other nine nodes Nc in network 30c.

  Each node Nc need not have the same storage capacity, such capacity does not need to be fixed, and is dynamically allocated automatically or manually as demand on a particular node Nc changes. However, it should be noted that for purposes of explanation, a node Nc in the network 30c is configured with a limit of nine other nodes.

  The database Dc of each node Nc holds the concept of “core”. If a particular node Nc is not included in a particular database Dc, the core represents a default path through which you can find the given node Nc. As shown in FIG. 14, network 30c includes a core Cc that exists along link L6c, the details of which are described in more detail below. In general, ensuring that there is at least the aggregate storage capacity of the database Dc that includes the core Cc, sufficient to ensure that the database Dc that defines the core Cc has knowledge of every node Nc in the network 30c. Currently preferred. Therefore, the size of the network based on the architecture of the network 30c is a size that is in time for the aggregate storage capacity of the two nodes Nc that define the core Cc. Thus, in this example, node N6c and node N9c have sufficient capacity in a cluster so that nine rows of each of databases D6c and D9c are sufficient to hold knowledge about every node Nc in network 30c.

  Thus, each node Nc “listens” for more other nodes Nc than the node Nc stores when executing the method 200. Thus, each node Nc also operates to perform a prioritization operation that selects nine from the other nodes Nc in the network 30c in order to retain knowledge about the other nodes Nc in its database Dc. Is possible. Such a prioritization operation may determine which of the other nodes Nc is the closest, which of the other nodes Nc carries the most traffic, and which node generally sends the payload traffic to which of the other nodes Nc. It can be based on any one or more prioritization criteria or combinations thereof, such as whether to transmit or other criteria that would occur to those skilled in the art. Thus, such prioritization criteria provide the “rank” of each node Nc in importance ranking, whereby the ranking entered in the database Dc, and node knowledge to other nodes Nc in the network. Determine the order in which to be sent.

In this example, the prioritization criteria for each node Nc is assumed to be ordered and entered into its database Dc to retain the following knowledge.
(A) Another node Nc closest to the node Nc (“proximity node Nc”). The neighboring nodes Nc are ranked in the order of proximity.
(B) An originating or destination node Nc ("originating or destination node Nc") that the node Nc must have knowledge of in order to pass payload traffic for the originating or destination node Nc. Originating or destination nodes Nc are ranked according to the amount of payload traffic transmitted for them and are preferred over neighboring nodes.
(C) Another node Nc with which the node Nc sends or receives payload traffic (“payload traffic node Nc”). Payload traffic nodes Nc are ranked according to the importance of one payload traffic compared to another payload traffic, and take precedence over all neighboring nodes and up to half the originating or destination node Nc. The importance of payload traffic can be based on traffic volume or traffic speed.
(D) Up to nine other nodes Nc during a particular cycle of method 200.

It should be reiterated that the prioritization criteria described above have been simplified for purposes of illustrating the present invention. In another currently preferred embodiment, the nodes are ranked by their distance based on the labeled data stream values except as follows.
1. This node is in the path of a high-speed propagation path for this destination node (“HSPP”, described in more detail below), and this directly connected node is
If in the path to the core and the HSPP is a notification HSPP,
One of the nodes that told us about this HSPP and the HSPP is the requesting HSPP.
2. If this node is marked as in the data stream towards this destination node.
If a node is labeled as in a data stream, its directly connected nodes that do not mark it as in the data stream will be given a distance based on a zero data stream (herein a distance based on a stream or “ (Also called DFS)). The node conveys a DFS equal to the link cost (“LC”) associated with the service characteristics of the link to the destination node to the directly connected node marking it as in the data stream. This is explained in more detail below.

  The formation of the core Cc in the network 30c will now be described. In the network 30c, it is first assumed that nodes N2c to N13c are connected by links L1c to L11c, as shown in FIG. It is also assumed that node N1c and node N14c are not initially connected to the rest of network 30c.

  Initially no node Nc is attempting to send payload traffic to another node Nc, and method 200 is performed by each of nodes N2c to N13c, and their individual databases Dc are prioritized as described above. It is also assumed that they are entered according to the attached criteria. FIG. 15 shows another node Nc input to the database D2c, shown as a closed dashed diagram, referred to herein as the knowledge path block K2c-xc. The knowledge path block K2c-xc surrounds all the other nodes Nc recognized by the node N2c, that is, the nodes N3c to N10c and the node N12c. FIG. 16 shows another node Nc input to the database D6c, shown as a closed dashed diagram, referred to herein as the knowledge path block K6c-xc. Knowledge path block K6c-xc surrounds all other nodes Nc recognized by node N6c, that is, nodes N2c to N5c, nodes N7c to N10c, and node N12c. Although not shown in the figure, those skilled in the art will appreciate the contents of other databases Dc at this point in this example.

  Here, it is also useful to mention that payload traffic between any of nodes N2c-N7c and any of nodes N8c-N13c needs to pass through link L6c. Thus, in this network, link L6c represents the “core” of network 30c at this point in the example. In FIG. 14, the core is shown as an ellipse surrounding the link L6c, and is indicated by Cc. The fact that the link L6c is in particular the core Cc of the network 30c need not be explicitly maintained in each database Dc. Rather, each database Dc determines a “best neighbor” that indicates the neighbor that is the best next step to reach the core Cc. The “best neighbor” to reach the core Cc examines the database Dc, and which neighbor Nc is the most “best neighbor” to reach other nodes that are explicitly held in the database Dc. It can be determined by finding frequently referenced. If no adjacent node Nc appears most frequently as the best adjacent node, the best adjacent node appearing in row 1 associated with the other highest ranked node is selected as the best adjacent node to reach the core Can be done. A core is formed when two adjacent nodes Nc indicate each other as the best adjacent nodes to reach the core.

  (When this core determination method is applied to the previous example, in Table XII and FIG. 11, for node N1a, the best neighbor node to the core of network 30a is node N2a, and for node N2a, the best neighbor node to the core of network 30a is Recall that node N3a, for node N3a, the best neighbor to the core of network 30a is node N2a, and for node N4a, the best neighbor to the core of network 30a is node N2a. Since the node N3a indicates the node N2a, the link L2a is the “core” of the network 30a.

  When a network, such as network 30c, is first initialized, the method 200 is performed a sufficient number of times until input is made to the database Dc until the database Dc remains substantially stable. It should be clarified here that the core of this is formed. Also, when the node Nc is added or deleted, or when the link Lc is added or deleted (and / or other factors that affect the overall state of the network change), the position of the core Cc changes. And / or multiple cores may be formed.

  Based on the examples shown in FIGS. 14-16, referring now to FIG. 17, it is assumed that two new links are added to the network 30c. Specifically, link L12c is now joined to nodes N1c and N2c, and link L13c is now joined to nodes N13c and N14c. Even if method 200 is performed by nodes N1c and N14c and re-executed by the remaining nodes Nc, in this particular configuration of network 30c, the location of core Cc at link L6c does not change eventually. However, the contents of each database Dc may change according to the prioritization criteria described above. For example, the node N2c adds the node N1c to the database D2c and deletes the node N12c from the database D2c.

  It should also be noted that the node N1c inputs knowledge about the nodes N2c to N10c to the database D1c, and the node N14c inputs knowledge about the nodes N5c to N13c to the database D14c. Therefore, the node N1c and the node N14c do not have knowledge about each other. Now assume that node N1c wants to send payload traffic to node N14c.

  Since node N1c has no knowledge of node N14c, at this point, method 800 shown in FIG. 18 may be performed to obtain such knowledge. Beginning at step 810, originating node N1c receives a request to send payload traffic to destination node N14c. Such a request can come from another application running on the computing environment associated with originating node N1c.

  (As an aside, as will become more apparent from the further teachings of this specification, translating this entire method more spokenly, the request sent to the adjacent node is: "You will receive route information for my destination node. If you can see, can you tell me about that information so that I can make the right choice where to send the payload data? " If you don't know where to send it, the payload times out (if a timeout is set), or that space is needed for other packets, or you can route to the directly connected node Continue to have that payload until you are informed of the possible route updates.)

  Next, in step 820, a determination is made whether the destination node to which the payload traffic is addressed is found in the local database Dc. Recall that in this example, database D1c does not contain information about destination node N14c, so the result of this determination is “No” and method 800 proceeds from step 820 to step 830. (However, if the destination node is present in the database D1c, in step 830, the payload traffic is described in relation to the network 30a of FIG. 12 or the network 30b of FIG. 13 via the best neighboring node identified in the database. Can be sent in much the same way as was done.)

  Next, at step 830, an inquiry is sent to the core for knowledge about the destination node N14c. Such a query is sent by each best neighbor node along the path of “best neighbor node” to reach core Cc until the query reaches node Nc with knowledge of destination node N14c. It is handed over to. Thus, each node Nc receives the query, checks its own database Dc, and if it has knowledge about the destination node N14c, sends such knowledge to the source node N1c in the reverse direction. To do. If the node Nc that received the query does not have knowledge of the destination node N14c, the node Nc is the best neighbor to reach the core Cc until the query reaches a node Nc that has knowledge of the destination node N14c The query is passed to the adjacent node. In this example, according to the prioritization criteria defined above, since node N9c has knowledge of node N14c, the query from node N1c is sent from node N2c to node N3c, node N6c, and finally node N9c. Follow the path to get to. Therefore, the knowledge about the node N14c is finally passed to the node N1c through the nodes N6c, N3c, and N2c in the reverse direction, and the nodes N6c, N3c, and N2c each transfer payload traffic for the node N1c. Records of knowledge about node N14c are kept in their respective databases Dc so that they can be sent.

  Next, at step 840, a response to the query generated at step 830 is finally received by the originating node Nc. Thus, in this example, node N1c receives knowledge about node N14c from node N9c, and at step 850, node N1c updates its database D1c with knowledge about node N14c. The method 800 then proceeds from step 850 to step 830 where payload traffic is transmitted from the node N1c to the node N14c in substantially the same manner as described in connection with the network 30a of FIG. 12 or the network 30b of FIG. Can be done.

  Referring now to FIG. 19, based on the example shown in FIG. 17, it is assumed that three new links are added to the network 30c. Specifically, the link L14c is added to the node N12c and the node N8c, the link L15c is added between the node N8c and the node N5c, and the link L16c is added between the node N5c and the node N2c. Each node Nc performs the method 200 multiple times in order to absorb knowledge about these new links Lc. Such knowledge propagates throughout the network 30c and eventually the path of payload traffic from node N1c to node N14c proceeds through nodes N2c, N5c, N8c, N12c, and N13c.

  If the links L14c, L15c, and L16c existed before the nodes N1c and N14c gained knowledge about each other, the node N1c is first configured as described in connection with FIGS. Now that knowledge about node N 14c is acquired via core Cc, then the optimal path (ie, the path with the minimum number of hops via the best neighbor) converges to the example shown in FIG. I want you to understand.

  Method 800 relates to “pulling” knowledge about destination node Nc that is not known by the originating node from core Cc, but if a new destination node Nc joins network 30c, that node Nc Can be “pushed” to the node of the core Cc so that when the method 800 is executed, the originating node Nc ensures that the information about the new destination node Nc is in the core Cc. Can be found. In the example given in FIG. 14, such a “push” of knowledge was not required by the execution criteria that automatically ensured that node N9c of core Cc gained knowledge about node N14c. However, in other configurations of the network 30c, a “push” of knowledge about the node Nc in the core Cc may be desirable.

  Although only certain combinations of the various features and components of the present invention have been described herein, the desired portions of the disclosed features and components and / or alternative combinations of these features and components However, it will be apparent to those skilled in the art that it can be utilized as needed. For example, although the above description contemplates a substantially synchronized execution of method 200 by each node N (and variations thereof), such a synchronized execution is not necessary and is used to simplify the description. Please understand that it was only done.

  As another variant, each node N (and its variants) is not selected by the neighboring node N (and variants), even though the neighboring node N (and variants) is not selected as the best neighbor stored in the database D. It is also possible to keep an independent record of all information sent (and variants thereof). This allows node N to select the next best neighbor from the remaining neighbors N without re-running method 200 if the best neighbor is deleted, otherwise It must wait for update information from all remaining neighbors.

  Accordingly, the present invention provides a novel system, method and apparatus for networking.

  Still other embodiments of the invention are contemplated, and a review of some of these embodiments will provide a further understanding of the invention. In the embodiments shown below, some terms or concepts may be somewhat different from those in previous sections. Such differences should be considered as an alternative and / or supplement to previous embodiments.

  In general, the network architecture of the present invention allows individual nodes in a network to coordinate their operations, so that the sum of their operations allows communication between the nodes in the network. .

  Although the main limitation of existing ad hoc networks used in wireless environment networks is the ability to scale beyond hundreds of nodes, the network architecture and related methods of the present invention at least overcome the scalability problems of the prior art. Relax and overcome them in some situations.

  Accordingly, exemplary embodiments are set forth below for clarity of understanding. These examples are not intended to limit the generality of the methods and systems described herein, even if specific reference is made to numbers, other vendor software, or other details. . If two or more combined concepts can be implemented separately or can be useful separately, those skilled in the art will understand even if not explicitly described as such. Alternative embodiments should not be considered mutually exclusive unless specifically stated.

  In the following embodiments, the following terms are used.

Each node in the node network is directly connected to one or more other nodes via a link. A node can be a computer, a network adapter, a switch, a wireless access point, or any device that includes memory and has data processing capabilities. However, the form of the node is not particularly limited.

A link link is a connection between two nodes capable of transmitting information. The link between two nodes can be a number of different links that are “coupled” together. The link can be physical (such as wire), actual physical item (such as box, small device, liquid), computer bus, radio, microwave, light, quantum interaction, acoustic, etc. Can do. The link can be a series of different types of separate links. However, the form of the link is not particularly limited.

Calculation of link cost “Link cost” is a value that enables comparison between two or more links. In this document, the lower the “link cost”, the better the link. This is a standard approach and those skilled in the art will be aware of possible variations.

Link cost is a value used to describe the quality of a link. The link cost of a link is
1. Line quality 2. Operation possible time 3. Link consistency 4. Waiting time Bandwidth 6. Signal to noise ratio It can be based on (but not limited to) the remaining battery power of the node.

  Link costs can change over time as the factors on which they are based change.

  One skilled in the art could assign a link cost or create a dynamic discovery mechanism.

  It is recommended that the link cost assignment be consistent across the network. For example, two identical links in different parts of the network should have the same or similar link costs.

  It is recommended that the link cost of a pipe has an almost direct relationship to its quality. For example, a 1M bit pipe has 10 times the link cost of a 10M bit pipe. These link costs are used to find the best path through the network using Dijkstra's algorithm.

  Alternative embodiments include randomly varying the calculated link cost by a small random amount not exceeding (for example) 1% of the total link cost.

Node name Each node in the network has a unique name .

This unique name is
1. Can be generated by a node.
2. Can be assigned before starting the node.
3. It can be requested by a node to a central location in a manner similar to a DHCP (Dynamic Host Configuration Protocol) server. When a node requests a name from a central location using this described network, the node first picks a random unique name and uses that name to request a name from the central location.

  A node can keep its name permanently, or it can generate a new name at startup or at any desired time. If node A knows the name of node B, it can send a message to node B.

  Nodes can have multiple names to emulate several different nodes. For example, a node may have two names: “print server” and “file server”.

  A node can generate a new name for each new connection established for it.

  Although ports are described as message destinations, the use of ports in these examples is not intended to limit the invention to the use of ports only. Those skilled in the art will be aware of other mechanisms that can be used as message destinations. For example, the node can generate a unique name for each connection.

  Normally, a node should have a unique name. Alternative embodiments allow a node to share a name with one or more other nodes in the network. This will be explained in detail later.

  Implied by the inventors as to the number of names a node has, how often the node adds or deletes names, what the name is, and tells someone about the name or names selected by the node There are no restrictions.

  For clarity in this document, it is assumed that each node has only one unique name associated with it. This should not be considered as limiting the scope of the invention. A node can share the same name as one or more other nodes in the network.

A link that establishes a connection between nodes can be established between two nodes, and if these nodes want to establish a link, the nodes exchange some information to establish that connection There is a need to. This information can include a version number and the like.

  Alternative embodiments may include the exchange of “tie breaker” numbers, which allow nodes to make a selection between links that are otherwise equal. It is recommended that all directly connected nodes be given the same tiebreaker value. If Node A tells Node B that it has already seen an equivalent tiebreaker number from some other node, NodeB chooses a new tiebreaker number and sends that number to all directly connected nodes. There is a need to. This process is illustrated in FIG.

A request for a new tiebreaker number can be (for example) as follows:
struct sRequestNewTieBreaker [

// This structure is empty, if the node sees this message it will
// generate a new tie breaker value and tell all its directly connected
// nodes this new value

]

  Alternative embodiments may include the maximum number of nodes that this node wants to know about it. For example, if node A has limited memory, node A tells node B to teach node A about up to X different nodes.

  Alternative embodiments can include exchanging the link cost of the link used to establish the connection. If the link cost changes during network operation, the node can send a message to the effect that the link cost has changed to the directly connected node at the other end of the link. If link costs are exchanged, the nodes can agree on the same link cost, or different link costs can still be selected to indicate an asymmetric connection.

If all three alternative embodiments so far are included, the messages exchanged are (for example) as follows:
struct sIntroMessage [

// the number used to break ties
int uiTieBreakerNumber;

// the maximum number of destination nodes
// this node wants to know about.
int uiNodeCapacityCount;

// the link cost for the connection between these two nodes
float fLinkCost;
]

  FIG. 21 is a flowchart of the initialization process.

  Connections are assumed to be able to deliver messages in order and without error. If this is not possible, the connection is assumed to be treated as a “failure”.

Spreading Node Knowledge To send a message to Node B, Node A needs to know the name of Node B as well as the directly connected node or link that is the best next step to reach Node B.

  If node A or node B wants to be sent a message from another node, they must convey their name to at least one directly connected node.

  Once a node establishes a link to another node, it can begin sending node information. The node information includes the name of the node and the accumulated link cost for reaching the node. When the network has just been started, a node knows nothing about the names of other nodes except itself, so the initial cumulative link cost for a node that it knows (self) is zero.

  When a node receives knowledge about another node A from link L, it adds the link cost of link L to the accumulated link cost announced for node A and saves that information related to link L in database D. The link cost for node A received from connection L implicitly includes the link cost of that link L added to it when referenced from database D by this node.

  Each node stores the information it receives from each link. The node does not need to know the name of the node at the other end of the link. All the node needs to do is record the knowledge that the other end of the link is sending to it. A node stores all node updates that it has received from neighboring nodes.

  When Node N receives knowledge about Node B from a link, it compares its accumulated link cost with the accumulated link cost for Node B received from other links. Node N selects the link with the lowest cumulative link cost as its “best neighbor” for messages flowing to Node B. When Node N sends an update for Node B to a directly connected node, it tells them the name of the node and the lowest accumulated link cost received from that directly connected node.

  Cumulative link costs are additive. FIG. 22 illustrates this additive property.

  This process continues until knowledge about the nodes is spread throughout the network and each node selects one link as having the lowest cumulative link cost.

  This process is very similar to Dijkstra's algorithm for finding the shortest path through the network, or the Bellman Ford algorithm. Those skilled in the art will be aware of such techniques and variations that produce similar results.

  23 to 26 show the flow of node knowledge through the network. All links are assumed to have a cost of 1. This is considered merely an example and is in no way intended to limit the generality of the invention. For example, links can have different link costs, and the number of nodes and their specific interconnections can vary indefinitely.

  At no point does the node need to build a global view of the network topology. The node only knows about the node knowledge that the directly connected node conveyed to it. This type of network can be compared to a distance vector network by one skilled in the art.

  An alternative embodiment may use a tie breaker number (described above) to make a selection between two or more links with the lowest cumulative link cost.

The structure of the message that spreads the node knowledge is (for example) as follows:
struct sNodeKnowledge [
Name NameOfTheNode;
Float fCumulativeLinkCost;
]

  fCumulativeLinkCost should be set to 0 on the node with that particular name.

  An alternative embodiment may set fCumulativeLinkCost to non-zero on the node with that particular name. This can be used to impersonate the real location of the destination node. Setting fCumulativeLinkCost to a non-zero (eg, 50) on a node with that particular name does not affect network convergence.

When the link cost changes , the node needs to take the difference between the new link cost and the old link cost and add the difference to the cumulative link cost of all node information received from that link.

Shown below is exemplary pseudo code that shows how the cumulative link cost can be adjusted for each node update received from a link whose link cost has changed.
CumualtiveLinkCost = CumualtiveLinkCost + (NewLinkCost-
OldLinkCost);
If (CumualtiveLinkCost> INFINITY) CumualtiveLinkCost = INFINITY;

  Based on this change, the node reevaluates its “best neighbor” selection. A node needs to communicate to its neighbors about all nodes that have changed the minimum cumulative link cost for a particular destination node.

  For example, if the link cost of a link that is not selected as “best neighbor” for destination node A changes and the link is still not selected as “best neighbor” for destination node A, for node A The accumulated link cost remains the same and no update needs to be sent to the directly connected node.

Delete link (when link is deleted)
This can be considered the same as the link cost of that link going to infinity.

  For each destination node that has used this link as the “best neighbor”, the next “non-infinite” alternative best neighbor is selected. If there is no such alternative best neighbor, the “best neighbor” cannot be selected and all directly connected nodes are told an infinite cumulative link cost for those nodes.

  If “best neighbors” are not selected, messages destined for those nodes cannot be sent.

Large networks with large variations in large network interconnect speeds and node capabilities, guarantee that any given node can connect to any other node in the network, even if there are millions of nodes In order to do this, different techniques need to be used.

Using the method specific to the present invention, knowledge about the destination node is quickly spread throughout the network. There are three problems in large networks.
1. The bandwidth required to keep every node informed about all destination nodes increases so that no bandwidth remains for the data.
2. If a bandwidth that suppresses destination node updates is used to ensure that data flows, the propagation speed of destination node updates is greatly reduced.
3. A node that does not have enough memory to know about every node in the network will not be able to connect to any node in the network, and will limit the ability of nodes with sufficient resources to connect to every node in the network There are things to do.

  Solutions are found by introducing the idea of the “core” or center of the network.

  The core of the network often has a larger amount of memory and bandwidth than the average node and is often topologically centrally located.

  This new network system has no knowledge of the network topology, or knowledge of other nodes in the network other than the nodes directly connected to it, so the node approximates where the core of the network is Can only know.

  This can be accomplished by checking which link is the “best neighbor” for the majority of destination nodes. The directly connected link is selected as the “best neighbor” for the destination node because it has the lowest cumulative link cost. The lowest link cost is generally provided by the link closest to the final destination node. If a link is used as the “best neighbor” for more destination nodes compared to any other link, this link is considered a step towards the core or network center.

  An alternative embodiment may determine the best next step to reach some other node or beacon and use it as its “best next step to reach the core” .

An alternative embodiment may be a node that uses a factorial combination to determine what is its “next best step to get to the core”. These factors can be (but are not limited to) any combination of the following factors.
1. 1. Radio direction where a target beacon is found 3. GPS location coordinates and best next step to reach a location 3. One or more special marker nodes Any other externally measurable factor

  The node does not need to know where the network center is, only the best next step to reach the network center.

  A core can be defined as the case where two nodes have selected each other as the best next step to reach the core. There is nothing special about the core, the two nodes that form the core operate like any other node in the network operates.

  "Tie breaker" (passed at initialization) if there is a tie between a set of directly connected nodes as to which was selected as the "best neighbor" for the most destination nodes The directly connected node with the highest value is selected as the best next step to reach the core. This mechanism ensures that there are no loops in the non-trivial network (except for node A-> node B-> node A type loops). If this tie breaker embodiment is not used, a random selection may be made.

  This idea of using the “best next step to get to the core” of the nodes forms a hierarchy. This hierarchy can be used to push specific node knowledge up to the top of the tree within the hierarchy. The HSPP (described later) uses this hierarchy to push up (or lower) node knowledge within this hierarchy.

  FIG. 54 is an example of a network in which a directly connected node is selected as the best next step for each node to reach the core. The network is then reconfigured to better show the nature of the generated hierarchy. When the network topology changes, the formed hierarchy also changes.

An alternative embodiment for detecting isolated cores helps to detect “isolated cores”.

  A core is defined as two directly connected nodes selected as the best next steps to reach each other. FIG. 27 shows an example of this.

  When a node selects a directly connected node as “the best next step to reach the core”, it tells the directly connected node about the selection. This allows a node to detect when a node creates a core that other nodes do not use as their core.

The message passed can be as follows:
struct sCoreMessage [
bool bIsNextStepToCore;
]

  When a core is created, both nodes that form the core (node A and node B in this example) investigate to see how many directly connected nodes they have. If there are two or more direct connection nodes, both nodes check all other direct connection nodes.

  If the only directly connected node selected as the best next step to reach the core is the node that caused the core to be generated, this node selects the next best option and Make it the best next step to get to.

  This can help eliminate cores that can hinder the flow of knowledge to the real core.

Exemplary Alternative Method of Choosing the Best Next Step to Get to the Core The approach described so far is to score directly connected nodes for each destination node that has selected that directly connected node as the “best neighbor” Including assigning "1". The node with the highest count (or the second highest count in the case of an isolated core) is the best next step to reach the core.

  If the embodiment uses multiple “best neighbors” (such as multipath described later), each “best neighbor” selected for each destination node is assigned an appropriate score. Can do. Alternatively, only the “best neighbor” with the best latency (in the case of multipath) can be assigned a score.

  Instead of assigning a score of 1 to each directly connected node for each destination node that has chosen it as the best option, other values can be used.

  For example, log (fCumulativeLinkCost + 1) * 500 can be the assigned score. Other metrics can also be used. This metric has the advantage of giving greater weight to destination nodes that are farther away. In dense networks with similar connections and nodes, this type of metric can better help a more centralized core be formed.

  Another possible embodiment that can be used to extend the idea of giving greater weight to more distant destination nodes is to order all destination nodes by their link cost, and the most distant x% (eg 50%) ) Only to determine the best next step to get to the core.

Another embodiment may use a weight value assigned to each node. This weight can be assigned by the node that generated the name. For example, if this weight is added to the node update structure:
struct sNodeKnowledge [
Name NameOfTheNode;
Float fCumulativeLinkCost;
Int nWeight;
]

  The nWeight value (in the sNodeKnowledge structure) can be used to help the core be formed near stronger nodes. For example, the assigned score can be multiplied by 10 ^ Weight (10 is an example). This helps the core to be formed near one or two large nodes, even if they are surrounded by millions of very powerless nodes.

The nWeight value should be assigned in a consistent manner to all nodes in the network. Possible nWeight values by node type are as follows:

  These weight values are only suggestions and those skilled in the art will be able to assign values appropriate for their application.

Next step to reach the core in a network with asymmetric link cost This is an alternative embodiment for selecting the best next step to reach the core.

  If the link is given an asymmetric cost, for example, a link L joined to node A and node B has a cost of 10 when going from A to B and a cost of 20 when going from B to A, One alternative embodiment helps to form the core at a single location in the network.

  In one previous embodiment, the nodes agreed on the link cost of a particular link and used a “best neighbor” selection based on this shared link cost.

  If asymmetric link cost is used to determine the “best neighbor”, the use of symmetric link cost can be used to select the next step to reach the core. The use of symmetric link costs can help ensure that the core is actually formed.

  For each node it knows, the node determines which link is the best next step to reach that node. The node chooses this best next step based on the cumulative link cost and possibly the tie breaker number. This “best neighbor” is then given a score that is summed with the other scores assigned to it. The “best neighbor” with the highest score is selected as the best next step to reach the core.

  In this alternative embodiment, the node agrees on the alternative cost of the link with the node to which it is coupled. This alternative link cost is the same for both nodes. This alternate link cost is used to adjust the cumulative link cost. The selection of “best neighbor node” is performed using this alternative cumulative link cost. This “best neighbor” is the best next step to reach the core, even if it is the “best neighbor” that is chosen as the best next step to reach the actual node. Assigned.

The following equation shows how an alternative cumulative link cost can be calculated.
AltemativeCumulativeLinkCost = ActualCumulativeLinkCost + (AlternativeLinkCost-ActualLinkCost)

High-speed propagation path (“HSPP”)
Nodes that are not in the core of the network generally do not have as much memory as nodes in the core of the network, and other nodes connect to node N only when they have knowledge of node N You may lose knowledge about Node N that you can do. If these nodes lose knowledge, other nodes in the network cannot connect to that node N.

  Similarly, a node seeking to establish a connection with node Q faces the same problem. Knowledge about the node Q that the node is looking for does not reach the node fast enough, or perhaps if the node Q or the node trying to connect to it is surrounded by a low capacity node.

  One approach is to use an implicit hierarchy generated by the selection of each node for “best next step to reach the core”. Node knowledge is pushed up and down this hierarchy to the core. This allows for efficient transfer of node knowledge to and from the center of the network.

  Node knowledge can be pushed / pulled using a method referred to herein as a High Speed Propagation Path (“HSPP”). The HSPP can be thought of as one or more labeled paths between the node and the core. Once set, the path is retained until the node that generated it is deleted.

  There are two types of HSPP. The first is a notification HSPP. The notification HSPP pulls knowledge about a particular node towards the core. Nodes through which the HSPP passes are not allowed to lose knowledge of the nodes associated with the HSPP. All nodes generate a notification HSPP to send knowledge about themselves to the core.

  The request HSPP is generated only when a node is looking for knowledge about another node. The request HSPP operates in the same manner as the notification HSPP, except that instead of pulling knowledge towards the core, it pulls knowledge towards the node that created it.

  (In the context of HSPP, the terms “push” and “pull” are useful for explanation purposes, but in practice HSPP does not know the “rank” of a node in the node database; (Those skilled in the art will appreciate that it may be considered a somewhat unnatural term because it improves to be transmitted prior to knowledge of the current node.)

  The HSPP proceeds towards the core using the best next step to reach the core of each node. Each node's “best next step to reach the core” creates an implicit hierarchy.

  The HSPP is not a route for the user message itself, but rather maintains knowledge about the node or nodes in question, and sends knowledge about the node or nodes along the HSPP promptly. Force a node on the route. The HSPP also raises the priority of updates for node names associated with the HSPP. This has the result of sending route updates promptly towards the top of this implicit hierarchy.

  HSPP does not specify where user data messages flow. HSPP exists only to ensure that there is always at least one path to the core and to help the node form an initial connection to each other node. Once the initial connection is established, the node no longer needs to use HSPP.

  An HSPP can be referred to as belonging to a single node name or as being associated with a single node name. This in no way limits the number or type of nodes with which the HSPP can be associated. In this embodiment, the name of the HSPP is typically the name of the node that the HSPP is pushing / pulling from / to the core.

  An HSPP is tied to a specific node name or class / group of node names. When a node hosts an HSPP for a particular destination node, it immediately processes and transmits node knowledge about the node referenced by that HSPP.

  Node knowledge in this case can be considered an update of (for example) sNodeKnowledge.

An alternative embodiment can limit the process to:
1. 1. Initial knowledge about the destination node 2. When fCumulativeLinkCost of the destination node becomes infinite When the destination node's fCumulativeLinkCost moves from infinity to some other value

  This allows every node in the HSPP to always know about the node referenced by the HSPP if any one of the nodes in the HSPP can "see" one or more nodes referenced by the HSPP. Can be guaranteed.

  Node knowledge is not included in the HSPP. HSPP only sets up paths that have a very high priority for knowledge about a particular node or nodes. This means that node updates for those nodes referenced by the HSPP are sent immediately.

  HSPP is generally considered to be a bidirectional path.

  Alternative embodiments may have two types of HSPP. One type pushes knowledge about the node towards the core. This type of HSPP may be referred to as a notification HSPP. The second pulls knowledge about the node towards the node that generated the HSPP. This type of HSPP may be referred to as a request HSPP.

  When a node is first connected to the network, it can generate an HSPP based on the node name. This HSPP pushes knowledge about this newly created node towards the core of the network. The HSPP generated by this node can be retained for the lifetime of the node or as long as the node wishes to retain the HSPP. The HSPP is deleted if the node is disconnected or if the node determines that it no longer holds the HSPP. An alternative embodiment may make this HSPP a “push HSPP” instead of a bidirectional HSPP.

  When a node attempts to connect to another node N, it generates an HSPP that refers to that node N. This HSPP goes to the core and helps to pull knowledge about Node N to the node that wants to create and connect to Node N. An alternative embodiment may make this HSPP a “pull HSPP” instead of a bidirectional HSPP.

  If the node no longer wants to keep the HSPP (perhaps because a connection to node N is no longer needed), the node sent an HSPP update with “bActive” = false and the first HSPP with bActive = true. Can be sent to all directly connected nodes. This should only be performed by the node that generated the HSPP.

  Alternative embodiments may allow the requested HSPP to be held by the node that generated the requested HSPP for some time after the connection is disconnected to facilitate faster reconnection.

  Both types of HSPP go to the core. The HSPP that sends knowledge about the node to the core can be retained for the lifetime of the node. The request HSPP is probably held for the lifetime of the connection.

  An alternative embodiment causes the node that generated the HSPP to send it to all directly connected nodes, not just the best next step to reach the core of the network. This embodiment allows the network to become more robust during moving and shifting.

  One alternative embodiment includes ensuring that a node does not send more HSPPs to a directly connected node than the largest node requested by that directly connected node.

  HSPP does not specify where user data messages should flow, but only helps to establish (possibly non-optimal) connections between nodes or between one node and the core.

  The HSPP goes to the core even if it encounters node knowledge before reaching the core. An alternative embodiment can stop the HSPP before it reaches the core.

How an HSPP is established and maintained When a node is told about an HSPP, the connection between the node and the node that told it about the HSPP is broken until ordered to lose its storage of the HSPP or Until that time, the HSPP is memorized.

  In one embodiment where a node limits the number of nodes that it wishes to be communicated, that node stores as many HSPPs as it is given. A node should not send more HSPPs to a directly connected node than the maximum number of destination nodes requested by that directly connected node.

In some systems, the amount of memory available on a node is such that it can be assumed that there is enough memory and that no matter how many HSPPs pass through the node, the node can store them all. This assumption is very likely to be met, but the number of HSPPs on a node is roughly related to how close this node is to the core, and a node usually has a large capacity and therefore probably also a large amount of memory. This is because it is not close to the core as long as it is not.
UR = final receiver node US = final transmitter node

HSPP takes the following form:
struct sHSPP [

// The name of the node could be replaced with a number
// (discussed later). It may also represent a class of nodes
// or node name.
sNodeName nnName;

// a boolean to tell the node if the HSPP is being
// activated or removed.
bool bActive;

// a boolean to decide if this a UR (or US generated HSPP)
bool bURGenerated;

];

  In these descriptions, HSPP H is considered to be referred to as HSPP H regardless of what is bActive or bURGenerated (more generally, the HSPP type). HSPP H gets its name from the node name it represents.

An alternative embodiment may be when the name of the HSPP H is not bound to the node name (s) it references. The HSPP structure in this embodiment can be (for example) as follows.
struct sAlternateHSPP [

// a unique name to represent this HSPP
sHSPPName HSPPName;

// The name of the node could be replaced with a number
// (discussed later). It may also represent a class of nodes
// or node name.
sNodeName nnName;

// a boolean to tell the node if the HSPP is being
// activated or removed.
bool bActive;,

// a boolean to decide if this a UR (or US generated HSPP)
bool bURGenerated;

];

  The following description uses sHSPP (rather than sAlertHSPP) to explain how HSPP works. This should not be regarded as limiting the generality of this method.

  A UR-generated HSPP can also be referred to as a “notification HSPP” and a US-generated HSPP can also be referred to as a “request HSPP”.

  Even if the HSPP path is changed or disconnected, it is important that the HSPP does not loop back to itself. This should be ensured by the process by which the next step to reach the core of the network is generated.

  A node should never send an active HSPP H (bActive = true) to the node that sent the active HSPP H to it. The node records the number of directly connected nodes that it ordered to hold HSPP H (with bActive in the structure set to true). If this number drops to 0, the node communicates inactive HSPP H (bActive = false) to its directly connected nodes that have been sent active HSPP H (bActive = true).

  At a general level, the HSPP finds a non-loop path to reach the core and stops extending when it reaches the core. This is because the two nodes forming the core select each other as the best next step to reach the core. Since the active HSPP is not sent to the node that has already sent it the active HSPP, the HSPP is sent by only one node of the core of the two nodes.

  When the HSPP path is cut, the HSPP from the cut point to the core is deleted. The HSPP is deleted because the only node that communicated the active HSPP to it is deleted. This prompts the node on the core side from the disconnection point, and causes the node that has transmitted active HSPP H to transmit inactive HSPP H. In most cases, this process proceeds in sequence toward the core, deleting its active HSPP.

  The HSPP proceeds towards the core using the best next step to reach the core of each node.

  The purpose of the HSPP generated by the UR is to always maintain the path between the UR and the core so that all nodes in the system send a US-generated HSPP (request HSPP) to the core, thereby Is to be able to find.

  If node N receives active HSPP H from any of the directly connected nodes, node N will receive the best next to reach the core to one (or more) nodes selected as the best next step to reach the core. Assuming that the node (or nodes) selected as the step is not sending active HSPP H to node N, it forwards active HSPP H.

  If multiple active HSPP Hs arrive at the same node, that node forwards the HSPP with bURGenerated labeled true if any of the arriving HSPPs have bURGenerated labeled true.

  If the directly connected node selected as the best next step to reach the core changes from node A to node B ("best step to reach next core" is still active HSPP of the same name for this node All HSPPs sent to node A) are sent to node B instead. Those HSPPs sent to node A have HSPP updates with the “bActive” value sent to node A set to false, and HSPPs sent to node B have the “bActive” value set to true. Is done.

  An alternative embodiment assumes that if node A generates an HSPP, node A should send the HSPP to all directly connected nodes. This ensures that even if this node is moving quickly, its knowledge is always sent to or from the core.

  If node A establishes a connection to another node B, node A can use HSPP (referred to as requesting HSPP) to pull path information for node B to itself. This HSPP should also be sent to all directly connected nodes.

  One alternative embodiment has only one type of HSPP that moves data in both directions. This type of HSPP can replace both push / notify HSPP and pull / request HSPP. In this embodiment, the bURGenerated parameter is omitted.

  The HSPP need not be continuously retransmitted. Once the HSPP is established in a static network, no additional HSPP messages need to be sent. This will be apparent to those skilled in the art.

  Each node stores which direct connection node has communicated which HSPP, and the node generally also stores which HSPP it has communicated to the direct connection node.

Alternate HSPP Type This alternate embodiment can help maintain a connection in a low bandwidth environment.

In the previous embodiment, there were two types of HSPP:
1. Notification HSPP
2. Request HSPP

  In this embodiment, a new type of HSPP called “Priority Notification HSPP” is introduced.

  The “priority notification HSPP” is the same as the “notification HSPP” except that it is transmitted before all “notification HSPP”. This will be explained later.

  For example, if a node attempts to communicate with another node, or knows that another node is attempting to communicate with it, the node can change its notification HSPP to a priority notification HSPP.

The following table describes what type of HSPP the node will send to its best next step to reach the core given the type of HSPP that the node received for a particular destination node. .

  If the entry containing “Priority Notification HSPP” is ignored, the above table also shows how other embodiments determine which HSPP type should be sent for the best next step to reach the core. Is explained.

The HSPP structure can be modified as follows.
struct sHSPP [

// The name of the node could be replaced with a number
// (discussed previously)
sNodeName nnName;

// a boolean to tell the node if the HSPP is being
// activated or removed,
bool bActive;

// the HSPP Type (for ex: Request HSPP, Notify HSPP,
// Priority Notify HSPP)
int nHSPPType;
];

An alternative embodiment ordering the HSPP to be transmitted, to adjust the order of HSPP is transmitted.

  When a node receives an HSPP, it must order it before sending it. This ensures that the more important HSPP is transmitted first.

If the “priority notification HSPP” embodiment is not used, the order in which the HSPPs should be sent is as follows:
1. Request HSPP
2. Notification HSPP

When the “priority notification HSPP” embodiment is used, the order is as follows.
1. Request HSPP and priority notification HSPP
2. Notification HSPP

This alternative embodiment of removing simple loops can be used to prevent simple loops from forming.

  Those skilled in the art will appreciate variations on the “poison reverse”.

  If Node A selects Node B as the “best neighbor” for a message to Node N, it informs Node B that it has been selected.

For example, the node A can transmit the following message to the node B.
struct sIsBestNeighbour [
Name NodeName;
Boolean bIsBestNeighbour;
]

  If node A tells node B that it is the “best neighbor” for messages going to node N, node B will make node A the “best neighbor” for messages going to node N. It cannot be selected. If Node B is the only possible choice that Node B can make for a message to Node N, Node B will not select the “best neighbor” and make its accumulated link cost to Node N infinite Set.

This alternative embodiment of marking nodes as in the data stream can be used to label nodes that are in the data stream.

  In this embodiment, a node is considered “in the data stream” only if it is labeled as “in the data stream”. Nodes can forward payload packets without being marked as in the data stream. A node is not considered “in the data stream” if it is forwarding payload packets but is not marked as in the data stream.

  If node A attempts to establish a data connection to another node N in the network, node A selects node B as its “best neighbor” to node N and node B It is the “best neighbor” and conveys that Node B is in the data stream towards Node N.

  If Node B is informed that Node B is in the data stream by a directly connected node that has told Node B that it is the “best neighbor”, then Node B is the “best neighbor” for Node N. Tells the directly connected node C selected as “adjacent node” that node C is in the data stream.

For example, the structure of this message can be as follows:
struct sInTheDataStream [
Name NodeName;
Boolean bIsInTheDataStream;
]

If Node B is marked as in the data stream for a message going to Node N, it tells the node that Node B has chosen as the best next step to reach Node N that it is in the data stream. Node B is no longer labeled as in the data stream for the following reasons.
1. One (or more) directly connected nodes that told Node B that it was in the data stream were disconnected.
2. Because one (or more) directly connected nodes that told Node B that it was in the data stream all told Node B that it was no longer in the data stream.

  Node B then tells its “best neighbor” C that it is no longer in the data stream.

  A node is marked as being in the data stream only by this flag. Nodes can forward payload packets without being marked as in the data stream.

Stream-based link cost The term “stream-based link cost” may also be referred to herein as “flow-based hop cost”.

  This alternative embodiment can be used to order node updates within a network. This ordering allows the network to be much more efficient by sending updates to preserve and converge the data flow before other updates.

The sNodeKnowledge structure used to pass node knowledge can be modified as follows (for example):
struct sNodeKnowledge [
Name NameOfTheNode;
Float fCumulativeLinkCost;
Float fCumulativeLinkCostFromStream;
]

  fCumulativeLinkCostFromStream is incremented in the same way as fCumulativeLinkCost. However, if a node is in the data stream towards a particular node, it resets fCumulativeLinkCostFromStream to 0 before sending the update to its directly connected node.

  Just as fCumulativeLinkCost is initialized to 0, fCumulativeLinkCostFromStream is also initialized to 0.

  An alternative embodiment causes fCumulativeLinkCostFromStream to be reset as well for other reasons, such as user data messages passing through that node. Those skilled in the art will appreciate such variations.

  An alternative embodiment useful in a low bandwidth environment is to have a node set fCumulativeLinkCostFromStream to a non-zero value if the node is not exchanging user data with another node. When a node is communicating with another node, it sets fCumulativeLinkCostFromStream to 0. One alternative embodiment again sets the non-zero fCumulativeLinkCostFromStream to a multiple of the minimum, maximum, average (etc.) link cost for the link established by this node.

  When fCumulativeLinkCost becomes infinite, the last non-infinite fCumulativeLinkCostFromStream value is held. This is used to command when an infinite update should be sent to the directly connected node.

Alternative Link Cost Based on Streams This embodiment is similar to the previous embodiment, except that it is more useful in helping the network remove node knowledge.

  In the previous embodiment, fCumulativeLinkCostFromStream was reset to 0 when it encountered a node that was marked as being in the data stream. This embodiment changes what type of update is sent.

  The node A that generated the destination node E (which may also be described as the node A that generated the node name E used by the node A) indicates that it is in the data stream towards the node E If it is transmitted by B, the node update for the node E with fCumulativeLinkCostFromStream = fCumulativeLinkCost is transmitted to the directly connected node B. In most cases, this update sets both of these values to 0 because node A generated the name E.

All other nodes that did not tell Node A that it is in the data stream are fCumulativeLinkCostFromStream! = FCumulativeLinkCost is transmitted. For example,
fCumulativeLinkCostFromStream = fCumulativeLinkCost + 0.1f;

  Since fCumulativeLinkCost is normally 0, these directly connected nodes are notified of fCumulativeLinkCostFromStream of 0.1 and fCumulativeLinkCost of 0. 0.1 should be considered a representative example.

  If a node that is not the node that generated the destination node name (any node other than node A in this example) is labeled as “in the data stream” and fCulativeLinkCostFromStream = fCumulativeLinkCost, then that node All its directly connected nodes that have not been labeled as “in” will be notified of updates for node E with fCumulativeLinkCostFromStream = 0. The node communicates updates for node E with fCumulativeLinkCostFromStream = fCumulativeLinkCost to the node that marked it as in the data stream.

  At no point in this embodiment, fCumulativeLinkCost is not adjusted to fCumulativeLinkCostFromStream. Always fCumulativeLinkCostFromStream is adjusted to fCumulativeLinkCost.

Node Update Ordering In a large network, there can be a large number of node updates to send. This alternative embodiment allows the updates to be ordered by how important they are.

  This alternative embodiment assumes that fCumulativeLinkCostFromStream is used and HSPP is used. If only one of them is used, the ordering provided by the unused embodiment should be ignored.

  All nodes in the system are ordered by the fCumulativeLinkCostFromStream value sent to it by the selected “best neighbor” (the link cost of the connection is added to the value sent by the directly connected node). This ordered list can take the form of a TreeMap (in the Java example).

  If the previous embodiment is used, when fCumulativeLinkCost = fCumulativeLinkCostFromStream and the node is labeled as in the data stream, it is added to the TreM as if it had a fCumulativeLinkCostFromStream to be 0. .

  When an update to a destination node path needs to be sent to a directly connected node, this destination node is placed in a TreeMap held for each directly connected node. TreeMap is a data structure that allows items to be deleted therefrom in ascending key order. This allows more important updates to be sent to the directly connected nodes before less important updates.

Destination nodes placed in this TreeMap are ordered by their fCumulativeLinkCostFromStream values except in the following cases.
1. This node is in the HSPP path for this destination node, and this directly connected node is
a. If in the path to the core and the HSPP is a notification HSPP or there is only one type of HSPP,
b. One of the nodes that told us about this HSPP, where the HSPP is a requesting HSPP or there is only one type of HSPP.
2. If this node is in the data stream to this destination node
(bIsInTheDataStream = true and fCumulativeLinkCost =
fCumulativeLinkCostFromStream)

If the destination node belongs to one of these two groups, the item is placed at the top of the ordered update list maintained for each directly connected node. A typical example of pseudo code for this process is as follows.
float fTempCumLinkCostFStream = GetCumLinkCostFStream (NodeToUpdate);

if (NodeToUpdate for this connection belongs to group l or 2)
fTempCumLinkCostFStream = 0;

while (CurrrentConnection.OrderedUpdateTreeMap contains
fTempCumLinkCostFStream as a key)
[
Incrementf FempCumLinkCostFStream by a small amount
]

Add pair (fTempCumLinkCostFStream, NodeToUpdate) to
CurrrentConnection.OrderedUpdateTreeMap;

  Thereafter, destination node path updates are sent in this order. When the destination update is processed, the destination node is removed from this ordered list (CurrentConnection.OrderedUpdateTreeMap). This ordering ensures that more important updates are sent before less important updates.

fTempCumLinkCostFStream should also be used for each connection to determine which destination node updates should be sent. For example, assume that there are five destination nodes with fTempCumLinkCostFStream values as follows:
1.202—Destination Node D
1.341-Destination node F
3.981-Destination Node G
8.192-Destination Node B
9.04-Destination node M

  A directly connected node requests up to four destination nodes to be sent to it. This node sends only the first four of this list (the node does not send updates for destination node M).

If destination node G changes its fTempCumLinkCostFSStream from 3.981 to 12.231, the new list is:
1.202—Destination Node D
1.341-Destination node F
8.192-Destination Node B
9.04-Destination node M
12.231-destination node G

In response to this update, this node schedules updates for both destination node G and destination node M. (Not assuming HSPP or data stream) CurrentConnection. The ordered pairs in OrderedUpdateTreeMap are as follows:
Position 1- (9.084, M)
Position 2-(12.231, G)

  This node then sends an infinite update for node G. This node then schedules a delayed transmission for node M (see “Delayed Transmission”).

The infinity destination node update ensures that the message required to pass this information is sent for the node that obtains the infinity update. This example includes several different embodiments, and those that are not used can be omitted by those skilled in the art.
a. fCumulativeLinkCost = INFINITY
b. fCumulativeLinkCostFromStream = INFINITY
c. bIsBestNeighbour = FALSE
d.bIsInDataStream = FALSE

  When an update for destination node M is sent, it becomes non-infinite.

Delayed transmission This alternative embodiment helps to remove node knowledge from the network if the node is removed from the network.

  If node knowledge is not removed from the network, the proper hierarchy and core will be in trouble.

  If this is the first time a destination node update is sent to the directly connected node, or if the last update sent to this directly connected node has an infinite fCumulativeLinkCost, the update should be delayed.

  For example, if the connection has a latency of 10 ms, the update should be delayed by (latency + 1) × 2 ms, or 22 ms in this example. This latency should also be a multiple of the delay between control packet updates (see “Propagation Characteristics”).

  Those skilled in the art will be able to experiment to find a good delay value for their application.

An exception is made if any of the following conditions are met:
1. This node is in the HSPP path for this destination node, and this directly connected node is
a. If in the path to the core and the HSPP is a notification HSPP or there is only one type of HSPP,
b. One of the nodes that told us about this HSPP, where the HSPP is a requesting HSPP or there is only one type of HSPP.
2. If this node is in the data stream towards this destination node.
(bIsInTheDataStream = true and fCumulativeLinkCost =
fCumulativeLinkCostFromStream)

  When an infinite update is scheduled to be sent (by being placed in CurrentConnection.OrderedUpdateTreeMap), but not sent until it is scheduled to be sent (because it is delayed) Infinity must be sent first, then non-infinity updates should be delayed again before being sent.

This alternative embodiment of cycling the destination node from infinity to non-infinity helps the node knowledge be removed from the network when the node is removed from the network.

An update is sent to the directly connected node N if any of the following criteria for node A is met:
1. An alternative embodiment is used that limits the number of node updates that can be sent to a node,
Directly connected node N sends a non-infinite update for this destination node A, but node A's new fTempCumLinkCostFSstream value (see above) is X (X requests that directly connected node N be conveyed) Criterion that it is greater than the fTempCumLinkCostFStream value of the other node.
2. Criteria that node A's fTempCumLinkCostFStream is greater than any other node's fTempCumLinkCostFStream sent to this directly connected node N.

  This node sends an infinite update for this destination node A to the directly connected node N. Then, after an appropriate delay (see Delayed Transmission), this node will send a non-infinite update for this destination node to the directly connected node, unless this node A still meets criterion 1. Send.

  This is part of the technique used to help remove bad path data from the network and automatically remove loops.

  An infinite update is an update in which the fCumulativeLinkCost value is set to infinity (see above for a more complete definition).

It is a recommended approach to decide to send an infinity update (after some time a non-infinity update for the same destination node) when the destination node meets the previous criteria. An alternative technique for triggering an infinite update followed by a delayed non-infinite update is
1. When fTempCumLinkCostFS is increased by a certain ratio or amount within a certain period of time, for example, when fTempCumLinkCostFS is increased more than 10 times the connection cost within 5 seconds,
2. This is done when the position of this destination node in the ordered list moves more than (for example) 100 positions in the list or (for example) more than 10% within X seconds. Yes (but not limited to).

  One skilled in the art will be able to determine an appropriate increase in fTempCumLinkCostFSStream and an appropriate timing value to trigger an infinite / non-infinite transmission.

  An alternative embodiment may use fCumulativeLinkCostFromStream instead of fTempCumLinkCostFStream.

  If a previously unknown destination node appears at the top of the list, infinity does not need to be transmitted because the directly connected node has not previously been informed of non-infinite updates. However, telling the directly connected node about this destination node should be delayed.

This delayed transmission need not be performed when any of the following conditions is satisfied.
1. This node is in the HSPP path for this destination node, and this directly connected node is
c. If in the path to the core and the HSPP is a notification HSPP or there is only one type of HSPP,
d. One of the nodes that told us about this HSPP, where the HSPP is a requesting HSPP or there is only one type of HSPP.
2. If this node is in the data stream towards this destination node.
(bIsInTheDataStream = true and fCumulativeLinkCost =
fCumulativeLinkCostFromStream)

End User Software This network system and method can be used to emulate most other network protocols or as the basis for entirely new network protocols.

  It can also serve as a “routing center” replacement for other protocols.

  In this specification, TCP / IP is used as an example of a protocol that can be emulated. The use of TCP / IP as an example is not intended to limit the application of the present invention to TCP / IP.

  In TCP / IP, when a node is activated, it does not inform the network of its presence. There is no need to inform because the name (IP address) of the node determines the location of the node. In the present invention, a node needs to be known to the network for its presence and needs to provide a guaranteed path to itself to the network. This is explained in more detail elsewhere.

If end user software ("EUS") wishes to establish a connection, it can do so in a manner very similar to TCP / IP. In TCP / IP, the connection code is similar to:
SOCKET sNewSocket = Connect (IP Address, port);

In the present invention, “IP address” is replaced with a globally unique identifier (“GUID”).
SOCKET sNewSocket = Connect (GUID, port).

  In fact, if the IP address can be guaranteed to be unique, the IP address can act as a GUID to provide a seamless replacement of the existing TCP / IP network stack according to this new network invention.

  One way to guarantee a unique IP address is to have each node generate a random GUID and then use it to direct communication to request a unique IP address that can be used as a GUID (Dynamic Host Configuration Protocol). ) To do with a like server. The node then discards the first GUID name and uses only this IP address as the GUID. Using an IP address in this context means that the IP address does not necessarily have to reflect the node location in the network hierarchy.

  Once a connection to the destination node is requested, the network determines the route to the destination (if such a route exists) and continually improves the route until an optimal route is found.

  The receiving side, except that the request to determine the IP address of the connecting node generates a GUID instead (or the IP address is the address used as the GUID), TCP / IP It seems to be the same.

  This approach provides routing through the network and those skilled in the art will understand how different flow control approaches may work better in different networks. For example, a wireless network may require a technique that does not lose packets when the incoming data rate exceeds the outgoing connection rate.

  FIG. 28 shows an example in which this routing method is adapted to the TCP / IP embodiment.

  One skilled in the art will appreciate that this new routing approach enables a TCP / IP-like interface for end-user applications. This is an example that is not intended to limit this routing approach to any particular interface (eg, TCP / IP) or application.

Connecting two nodes through a network The following is an example of one approach that can be used to connect two nodes in this network. This example (as well as all examples herein) is not intended to limit the scope of this patent. Those skilled in the art will know many variations.

  If an alternative embodiment using HSPP is not used, ignore the part about HSPP.

  If node A wants to establish a connection with node B, it first sends a request HSPP (described above) to all directly connected nodes. This request HSPP captures and holds the path information about the node B in the node A. This request HSPP is sent even if node A already has knowledge of node B.

  If an alternative embodiment using “priority notification HSPP” is used, node A can change its notification HSPP to priority notification HSPP and notify all directly connected nodes. This can help connectivity in a low bandwidth mobile environment because it allows communicating nodes to disseminate that information before nodes that are not communicating.

  This HSPP goes to the core even if it encounters node path knowledge before reaching the core.

  Once the node A has a non-infinite best next step for reaching the node B, the node A sends a “connection request message” toward the specific port of the node B. This request is sent to the directly connected node selected as the “best neighbor” for the message towards Node B.

  When the “mark data stream” embodiment is used, node A tells its directly connected node selected as “best neighbor” that it is in the data stream towards node B.

  The use of ports is merely an example and is not intended to limit the scope of the invention. A possible alternative could be a new node name, especially for incoming connections. Those skilled in the art will know the variations.

  Node A continues to send this message every X seconds (eg 15 seconds) until a sConnectionAccept message is received or a timeout occurs without being received (eg 120 seconds). The connection request message may include the node A GUID and the port to which the connection response message should be sent. The connection request message can also include an nUniqueRequestID that is used to allow Node B to detect and ignore duplicate requests from Node A.

The connection request message is (for example) as follows:
struct sConnectionRequest [

// the name of node A, could be replaced with a number
// for reduced overhead.
sNodeName nnNameA;

// Which port on node A to reply to
int nSystemDataPort;

// Which port to send end user messages to on node A
int nUserDataPort;

// a unique request id that node B can use to
// decide which duplicate requests to ignore
int nUniqueRequestID;

]

  When Node B receives the “Connection Request” message from Node A, it generates a request HSPP for Node A and sends it to all directly connected nodes. This captures and holds the path information for node A in node B.

  If an alternative embodiment using “priority notification HSPP” is used, Node B can change its notification HSPP to priority notification HSPP and can notify all directly connected nodes. This can aid connectivity in low bandwidth mobile environments.

  If an alternative embodiment “in the data stream” is used, node B waits until it knows where its best next step to reach node A and then routes to node A “data stream” Label as "inside".

Thereafter, the node B transmits an sConnectionAccept message to the designated port (sConnectionRequest.nSystemDataPort) of the node A. The message is as follows:
struct sConnectionAccept [

// the name of node B
sNodeName nnNameB;

// the port for user data on node B
int nUserDataPortB;

// the unique request ID provided by A in the
// sConnectionRequest message
int nUniqueRequestID;
]

  The sConnectionAccept message is sent until node A sends an sConnectionConfirmed message that is received by node B or a timeout occurs.

The sConnectionConfirmed message is as follows.
struct sConnectionConfirmed [

// the name of node A, could be replaced with a number
// for reduced overhead.
sNodeNarne nnNameA;

// the unique request ID provided by A in the
// sConnectionRequest message
int nUniqueRequestID;

]

  If a timeout occurs during processing, the connection is considered to have failed and is discarded. The request HSPP generated by both nodes is deleted, and the “in data stream” flag (if added) is deleted.

  Once the connection is established, both nodes can send user data messages to each other's respective ports. These messages are then forwarded to the end user software (in the case of TCP / IP) via a socket.

  An alternative embodiment does not require a connection to be established, and simply sends an EUS message / payload once the route to the destination node is found.

Node name optimization and messages This alternative embodiment can be used to optimize message and name passing.

  Every node update and EUS message / payload packet needs to have a way to identify the destination node to which they refer. Node names and GUIDs tend to be long and are inefficient to send with every message and node update. Nodes can make these transmissions more efficient by using numbers representing long names.

For example, if node A wants to tell node B about a destination node named “THISALONGNODENAM.GUID” first,
1 = 'THISISALONGNODENAME.GUID'
To Node B.

The structure for this can be (for example) as follows.
struct sCreateQNameMapping [

// size of the name for the node
int nNameSize;
// name of the node
char cNodeName [Size];
// the number that will represent this node name
int nMappedNumber;
];

  Thereafter, whenever node A wishes to send a destination node update or message, node A can send a number representing the node name (sCreateQNameMapping.nMappedNumber) instead of sending the long node name. If Node A decides that it no longer wants to tell Node B about the destination node called “THISALONGNODENAME.GUID”, it can tell Node B to erase the memory for that mapping.

The structure is as follows.
struct sRemoveQNameMapping [
int nMappedNumber;
];

Each node maintains its own internal mapping of which names are mapped to which numbers. Each node maintains a translation table so that names from directly connected nodes can be translated into its own naming scheme. For example, node A
1 = 'THISISALONGNODENAME.GUID'
Node B can use
632 = 'THISISALONGNODENAME.GUID'
Is used.

Thus, Node B has a mapping that allows it to translate Node A's numbering scheme into a numbering scheme that is understandable to Node B. In this example, it is as follows.
Node A Node B
1 632
. . . . . .
. . . . . .

The use of this numbering scheme also allows messages to be easily tagged as to which destination node the message is destined for. For example, when the system has a message of 100 bytes, the system reserves 4 bytes for storing the destination node name to which the message is transmitted at the head, and the message follows. In this way, the total message size is 104 bytes. An example of this structure also includes the size of the message.
struct sMessage [

// the number that maps to the name of the node where
// this message is being sent to
int uiNodeID;

// the size of the payload packet
int uiMsgSize;
// the actual payload packet
char cMsg [uiMsgSize];
]

  When this message is received by a node, the node looks up its translation table and translates the destination mapping number into its own mapping number. The node can then use this mapping number to determine whether this node is the destination of the payload packet or whether it needs to be sent to another directly connected node.

  These quick destination numbers can be placed in the TCP / IP header by those skilled in the art.

When to delete a name mapping this alternative embodiment is used to help remove a name mapping is no longer required.

  If the destination node continues to have an infinite fCurativeLinkCost longer than Xms (eg 5000 ms) and sends this update to all directly connected nodes, it deletes knowledge about this destination node.

  Initially, this node releases all memory associated with this destination node and releases the updates provided to it by the directly connected node. This node also deletes messages waiting to be sent to its destination node.

  The node then commands its directly connected node to remove the number-> name mapping for this destination node from storage.

  If all directly connected nodes tell this node that this node can also remove their number-> name mapping for this destination node from memory, this node will change its own number-> name mapping. Can be deleted.

  At this stage, there is no longer any memory associated with this destination node.

  A node should attempt to reuse an internal node number that has been erased from storage before using the new number.

Simpler Fast Routing This alternative embodiment is used to speed up packet routing.

  As an optimization, another column is added to the name mapping table indicating which directly connected nodes receive the message.

Thus, Node B has a mapping that allows it to translate Node A's numbering scheme into a numbering scheme that is understandable to Node B. In this example, it is as follows.
Node A Node B Directly connected node to which the message is sent 1 632 7
. . . . . .
. . . . . .

This allows the entire routing process to be a single sequence search. When node A sends a message with destination node 1 to node B, the routing process is as follows.
1. Node B generates a pointer to the mapping in question.
sMapping * pMap = & NodeMapping [pMessage->uiNodelD];
2. Node B translates the name.
pMessage-> uiNodeID = pMap->uiNodeBName;
3. The message is then forwarded to the designated directly connected node.
RouteMessage (pMessage, pMap->uiDirectlyConnectedNodeID);

  In order for this scheme to work correctly, a node needs to update these routing tables for all directly connected nodes if it decides which directly connected node to forward the message to.

  If directly connected nodes reuse internal code numbers and the number of destination nodes they know is less than the amount of memory available to store these node numbers, the nodes send messages Sequence search can be used for this.

  This provides O (1) message routing to the node (see above). If the node number provided by the directly connected node exceeds the size of memory available for the search array (but the total number of nodes still fits in memory), the node hashes from using array search You can move to using map search.

More complex fast routing This alternative embodiment helps to ensure that O (1) routing can be used and avoids the use of hash maps.

  To ensure that the node can always perform fast O (1) sequence search routing, the node can provide a unique node number-name mapping to each directly connected node. This ensures that directly connected nodes do not have to rely on the use of a hash table to perform message routing (see above).

  When generating these unique number-name mappings for directly connected nodes, this node ensures that all possible numbers are reused.

  Reusing these numbers ensures that the highest number used in the mapping never exceeds the maximum number of destination node updates required by that directly connected node.

  For each connection, the node needs to generate an integer array, whose offset corresponds to the node's own internal node ID, and the number stored in that offset is a unique number used for that directly connected node. Number-> name mapping.

The fast routing is then as follows (see above):
1. Node B generates a pointer to the mapping in question.
sMapping * pMap = & NodeMapping [pMessage->uiNodeID];
2. Node B translates the name.
pMessage-> uiNodeID = pMap->uiNodeBName;
3. The message is then forwarded to the designated directly connected node.
RouteMessage (pMessage, pMap->uiDirectlyConnectedNodeID;
4). The name is last changed again before sending.
pMessage-> uiNodeID = UniqueNameMapping [uiConnectionID] [pMessage-
>uiNodeID];

  UniqueNameMapping is a two-dimensional array, the first parameter is the connection ID, and the second parameter is the number used in the unique number-name mapping for the connection with that connection ID.

  Reusing the numbers used in the number-name mapping for each directly connected node requires an array of the same size as the maximum number of mappings used. The array is treated as a stack and the number to be reused is placed on this stack. The offset into the stack tells this node where to place the next number to be reused and where to pick the number to be reused.

  If a directly connected node requests a maximum number of destination nodes that is greater than the total number of destination nodes known by this node, a unique mapping scheme is not required for that directly connected node.

  If this situation changes, the mapping can be easily generated by one skilled in the art.

When to send user data packets User data packets can be sent whenever there is an available path. An alternative embodiment may allow QOS where a class of nodes have user data packets transmitted first. Those skilled in the art will know the variations.

  If there is no readily available route, the payload packet can be held for a while in the hope that a valid route will appear.

  Activity time (TTL) schemes can also be implemented by those skilled in the art. Instead of using hops (as in a protocol such as TCP / IP), the TTL can be a multiple of the fCumulativeLinkCost value for the destination node calculated by the node that generated the payload packet. Each node then subtracts the link cost of the link from which the packet was received from the TTL. If TTL falls below 0, the packet can be deleted. Those skilled in the art will recognize this as a standard TTL scheme that uses link costs instead of using hop counts (as in TCP / IP).

This alternative embodiment , which allows more important nodes to spread farther, allows some nodes to spread farther and / or faster in the network.

  In order for this embodiment to work well, most (if not all) nodes in the network need to follow the same rules.

  For nodes of a class that are labeled as more important, only a portion of the link cost is added to their fCumulativeLinkCost and / or fCumulativeLinkCostFromStream value. For example, if node D belongs to a more important node class and the normal link cost of link N is 10, for an update for node D, only 5 (for example) or half of the link cost will have its fCumulativeLinkCost And / or added to fCumulativeLinkCostFromStream.

How important a node is
1. Its scale (as explained above) 2. Arbitrary scheme based on node names Can be tied to another value or combination of values added to or present in the node update structure.

Congested or energy depleted node This alternative embodiment can help to draw network traffic away from an over congested node or a node operating in a battery depleted state.

  A node can increase its link cost if it is operating in an energy exhausted state or experiencing congestion. This helps to pull traffic away from this node experiencing the problem.

  It is useful for a node to change its link value slowly and wait for the change. This helps to avoid unstable network vibrations.

  If a node experiences congestion mitigation or if its battery condition improves, the node should slowly reduce its link cost to a normal value.

  Those skilled in the art will know about vibration problems and how to deal with these problems.

Node sharing names This alternative embodiment allows nodes to share names.

  In the case of a web server (for example) it may be important to provide more bandwidth and connectivity than a single server provides.

  If two or more nodes use the same name, the node attempting to connect to the node with that name connects to the nearest node (based on fCumulativeLinkCost).

  If the request is stateless (eg, requesting the main page of the website), the node can send the request immediately because the same result is returned no matter which node the request is forwarded to.

  When a node requests a stateful connection, it first connects to the nearest node with that name. That closest node then returns its unique name that can be used to establish a connection that requires state.

  For example, in the previously described sConnectionAccept structure, the returned node name (sConnectionAccept.nnNameB) can be the unique name of the node.

In networks that are larger than the propagation priority , bandwidth limitations for control messages need to be used.

  The total “control” bandwidth should be limited to a percentage of the maximum bandwidth available for all data.

For example, the minimum size can be 4K and 5% of the maximum bandwidth can be specified for each group. For a simple 10MB / s connection, this means 4K information packets = 4096 / (10MB / s x 0.05)
= 0.0819s
Means to send every.

  Therefore, in this connection, the control packet can be transmitted every 0.0819 s or about 12 times per second.

  The percentages and transmitted block sizes are examples and can be varied by those skilled in the art to better meet their application requirements.

Bandwidth limit messages These messages should be concatenated together to fit the size of the block to which the control message fits.

  If the control message refers to the destination node name by its quick reference number and the directly connected node does not know the number, a quick reference (number-> name mapping) should be made prior to the message.

  There should be a discrepancy between the amount of control bandwidth allocated for path updates and the amount of control bandwidth allocated for HSPP updates. For example, 75% of the control bandwidth can be allocated for path updates and the remaining 25% can be allocated for HSPP updates. Those skilled in the art will be able to change these numbers to better suit their implementation.

Multi-Path Network This section of the specification describes one embodiment that allows multiple paths for end user data to be formed between two communication nodes. This embodiment also allows the path to be moved and alternated to avoid congestion.

  This embodiment uses the idea of nodes and queues. The queue is used as the destination for messages (like the node name used in earlier sections of this document). The terms in this section of the specification may be slightly different from the previous ones, but those skilled in the art will be able to tell which terms are equivalent.

  Any definitions or concepts provided in this section of this document should not be considered as invalidating or changing the meaning of the definitions or concepts in the preceding part of this document.

  One skilled in the art will be aware of possible variations.

  This network does not depend on any agent possessing global knowledge of the network.

  Network components are nodes and queues.

This network follows several principles.
General principles 1. The network uses a simple concept.
2. Decision making and knowledge are kept locally, avoiding the need for global knowledge.
3. There are no restrictions on system size or topology, node capacity, or structural flexibility.

These principles influence network design. The workings of these principles will be explained in detail later.
Individual principles A node sends a message only to the directly connected node that it designates as the selected destination.
2. A node is only for the selected destination if the latency of the data in the queue on that node is greater than the latency of the selected destination minus the minimum latency of all selected destinations Send a message.
3. Nodes that are not currently in the data stream have only one selected destination. Nodes in the data stream have a plurality of selected destinations.
4). When looking for a better selected destination, nodes that are not in the data stream use passive loop checking, and nodes that are in the data stream use active loop checking.
5. The connection is established and held by the TCP / IP method.
6). Nodes in large networks look for knowledge in the core of the network.
Data flow principle A stream of data must not change the latency of its own path unless the flow exceeds capacity.

  It should be repeated that examples are given for clarity of understanding. These examples are not intended to limit the generality of the methods and systems described herein, even if specific reference is made to numbers, other vendor software, or other details. .

Node Each node in this network is directly connected to one or more other nodes. A node can be a computer, a network adapter, a switch, or any device that includes memory and data processing capabilities. Each node has no knowledge of other nodes except the node to which it is directly connected. The connection between two nodes can be several different connections that are "coupled" together. Connections can be physical (such as wires), actual physical items (such as boxes, small devices, liquids), computer buses, radio, microwaves, light, quantum interactions, etc. .

  No limitation on the form of connection is implied by the inventors.

  In FIG. 29, node A is directly connected to node B and node C. Node C is connected only to node A. Node B is directly connected to four nodes.

  A “selected destination” is a subset of any directly connected nodes. Only the “selected destination” is always considered a possible route for the message (discussed later).

  The “selected destination” is equivalent to the “best neighbor”. This terminology is used in this section to be somewhat misunderstood as “best neighbor” because there can actually be only one “best neighbor” but there can be multiple “selected destinations”. This is because it may occur.

Communication by the queue and message end user software (EUS) is performed using the queue. Queues are used as destinations for EUS messages / payloads as well as messages used to establish and maintain reliable communications. Every node that knows the existence of a queue has a corresponding queue with the same name. This corresponding queue is a copy of the original queue, but the contents of the queue on different machines are different.

  Messages are transferred between nodes using a queue of the same name. The message continues to be forwarded until it reaches the original queue. The original queue is the queue actually created by the EUS or system that is the recipient of the message.

  A node that did not create the original queue does not know which node created the original queue.

Each queue created in the system is given a unique label that includes an EUS or system assigned queue number and a globally unique identifier (GUID). The GUID is important because it ensures that there is only one queue initially created with the same name. For example,
Format: EUS QueueNumber.GUID
Example: 123456.af9491de5271abde526371

Alternative implementations can have several numbers that are used to identify a particular queue. For example,
Format: EUSAppID.EUS QueueNumber.GUID
Example: 889192.123456.af9491de5271abde526371

  Each node can support multiple queues. There is no requirement that a specific queue be associated with a specific node. A node is not required to store all queues communicated to it.

  If a node knows about a queue, it tells the node connected to it about that queue (described in detail later). The only node that knows the final destination of the message in the queue is the final destination node that originally created the queue. The node assumes that the node that passed the message is the final destination for the message.

  At no point does the node attempt to build a global network map or attempt to gain knowledge of the overall network except for the nodes to which it is directly connected. The only knowledge is that a queue exists, how long it takes a message to reach the node that originally created the queue, and a latency update from the original node reaches this node It is the maximum time it takes to do.

Latency Latency plays a central role in selecting the best path for data in the network. If Node B tells Node A that its latency is X seconds, if Node A passes the message to Node B, it reaches its final destination and is taken out of the queue by the EUS. That it takes X seconds.

This latency value calculated by Node B is as follows:
Latency = MinOverTimePeriod ([Bytes In Queue]) * [Bytes / Second Send Rate] +
[Lowest Latency of All Chosen Message Destinations] +
[Service time on this queue] + [Physical Network Latency]

  Min Over Time Period is the period determined by the time taken to perform the minimum of the five transmissions or receptions from the transmission and receiving nodes associated with this queue. It is also a minimum time of 30 ms (or a reasonable multiple of the fast system timer granularity). This will be explained in more detail later.

  Bytes / Second Send Rate is the best estimate of the rate of data flowing out of the queue on this node.

  Lowest Latency of All Chosen Message Destinations. All directly connected nodes that have knowledge of this queue provide latency to the node that originally created the queue. This is the lowest latency among all nodes that are the selected destination for this queue.

  Service Time On This Queue is the time it takes for a node to attempt to send data from all other queues other than this particular queue before returning to this particular queue.

  FIG. 30 shows how the service time can be calculated.

Calculating service time on a queue For each directly connected node, there is a list of queues that have that node as the selected destination and have the data to be sent in the queue.

  To service the queues fairly, the system cycles through these queues in a round robin fashion and sends messages from them to the “selected destination”. Each “selected destination” has its own list of queues that it independently circulates.

  When quality of service (QOS) is implemented, the order of processing can be changed to process “more important” queues more frequently.

  Some types of nodes have system timers where different resolutions are available. Since low resolution timers are many times faster to read, it makes sense to use a lower resolution timer to increase the performance of the node.

  The trade-off is that the algorithm for determining the service time on the queue is slightly more complicated.

  The system records the number of times a message could be sent from a particular queue by going through the queue list for the selected destination by incrementing the counter associated with that queue. To do. The system increments this counter only if the message can be passed from this queue to the network adapter associated with the selected destination. The system passes a message from the queue only if an appropriate queue token exists and passes the latency test. Both of these concepts are defined later.

  The node also records how many messages could be sent from all queues.

  The system continues to repeat this round robin process for at least 3 or 4 ticks of the low resolution timer. For Windows 2000, which is taken as an example and does not reduce the generality of this application, this is about 45 or 60 milliseconds. To increase the accuracy of this calculation, the number of ticks should be increased.

When this period elapses for a directly connected node, the system records the following statistics:
1. 1. Total number of messages sent to this directly connected node Total time taken in seconds for this process

  Each queue also records the number of messages sent from that queue to that particular selected destination during that period.

  These statistics are stored for two iterations, one for the process currently in progress and one for the last completed process. This allows the node to calculate the service time for its queue while collecting new data for the next service time value.

To calculate the service time for this queue with this particular selected destination (CD), the following equation is used:
Service Time = ([TotalMessagesSentToCD]-
[TotalMessagesSentFromQToCD]) /
[TotalMessagesSentToCD] * [TotalTimeInSecondsForIterations]

If there are multiple selected destinations, use the following formula to get the service time.
Service Time = 1 / (1 / [CD1Time] + 1 / [CD2Time] + ...))

  This value is only calculated if it is sent as part of the latency calculation. This reduces the computational overhead.

Physical network latency This is defined as:
The time required for a packet close to the average message size to be sent to a directly connected node and received by that directly connected node.

  This value is very similar to the “ping” value of a conventional TCP / IP network.

This physical network latency is added to the latency provided to the directly connected nodes each time a calculation is performed using the latency provided by the directly connected nodes. For example, physical network latency is used in the following cases.
1. When determining which is the selected destination with the lowest latency.
2. When passively detecting a loop when not in the data stream (discussed later).
3. When selecting additional selected destinations.

  This value can be initialized by sending a series of predefined packets directly to the connecting node and timing.

  During system operation, this value is recalculated based on actual execution.

Assuming the network card is continuously sending data, the system needs to record the amount of data sent, the average size of the message, and how much time has passed Only. The formula is as follows.
Physical Network Latency
= [AverageMsgSize] / ([TotalBytesSentDuringPeriod] / [ElapsedTime])
The period should be selected to be similar to the period used to calculate the service time.

End-user software Unlike a conventional network where each machine has an IP address and a port that receives a connection, this system works on a queuing concept.

When end-user software (EUS) creates a queue, it is similar to opening a port on a particular machine. However, there are some differences.
1. Unlike TCP / IP, where the machine's IP address and port number are required, all that is needed to connect to the queue is the name of the queue (eg, QueueName.GUID as described above). It is. The name of the queue need not necessarily have any relationship to the node, the node identifier, or the location of the node in the physical or network.
2. In TCP / IP, a node does not advertise its presence when connected to a network. Under this new system, when a node is connected to the network it tells it only to its directly connected neighbors. This information is not passed on in sequence.
3. This is not broadcast to the network when a port is opened to receive data under TCP / IP. In the new system, when a queue is created, the entire network is informed about the existence of this queue, in contrast to the handling of the node itself described in the previous “2”. Queue information is propagated only by communication from adjacent nodes to adjacent nodes.

  These features allow an EUS to have connections to other EUS without having any information about the location of individual nodes in the network.

A handshake protocol similar to TCP / IP is used to establish a connection between EUSs.
1. Node A: Create queue A1 and send a message with a request to open communication to queue B. It asks for a response to be sent to queue A1. The request has the following structure.
struct sConnectionRequest [

// queue Al (could be replaced with a number-
// discussed later)
sQNameType qnReplyQueueName;

// update associated with queue Al (explained
// later) Includes Latency, UpdateLatency, etc ..
sQUpdate quQueueUpdate;

]

  This message also carries the definition of queue A1 as it travels through the network. Thus, when this message arrives, there is already a set of nodes that can move the message from node B to queue A1.

  Node A does not find a response from node B in queue A1, and queue A1 on node A is not labeled as “in the data stream” (actual between node B and queue A1) If node A still has non-infinite knowledge about queue B (representing queue B, and therefore node B still exists and is functioning) Node A then resends this message.

  Node A resends the message every second or every much longer "Queue B Latency" seconds.

  Node B naturally ignores multiple identical requests.

If a node has two identical requests for it, it deletes all but one of these requests.
2. Node B: Send message to queue A1 saying "You created a special queue B1 to send messages. Allocating an X byte buffer to reorder out of order messages" To do.
struct sConnectionReply [
// queueB1
sQNameType qnDestQueueForMessages;

// update associated with queue B1 (explained
// later) Includes Latency, UpdateLatency, etc ..
sQUpdate quQueueUpdate;

// buffer used to re-order incoming messages
Integer uiMaximumOutstandingMessageBytes;
]

  This message also carries the definition of B1 as it travels through the network. As a result of this mechanism, there is already a set of nodes that can move the message from node A to queue B1 when this message arrives.

  Node B does not find a response from node A in queue B, queue B1 on node B is not “in the data stream”, and node B still has non-infinite knowledge about queue A1 If so, Node B resends this message.

  Node B resends the message every second or every much longer "queue A1 latency" seconds.

  Node B receives the sConfirmConnection message and continues to retransmit this message until queue B1 is marked as “in the data stream”.

  Node B naturally ignores multiple identical sConfirmConnection responses.

If a node has more than one identical response to it, it deletes all but one of these requests.
3. Node A: Whenever a node receives sConnectionReply from Node B on queue A1 and has knowledge of queue B1, it sends a response to queue B indicating that the connection has been successfully established.
struct sConfirmConnection [

// the queue being confirmed
sQNameType qnDestQueueForMessages;

]

  If a node has two identical sConfirmConnection messages for it, it deletes all but one of these messages.

  By attaching the queue definition to the handshake message, the time overhead required to establish a connection is minimized. It is minimized because the node does not have to wait for the queue definition to propagate through the network before it can transmit.

  Node A can then begin sending messages. Node A must not have more bytes than the given buffer size at a time during execution. Node B sends an acknowledgment to the received message from node A. Node B sends these acknowledgments as messages to queue A1.

  An example of the configuration of nodes and queues is as shown in FIG.

  Acknowledgments to sent messages can be represented as a series of messages. Acknowledgments are associated together. For example, acknowledgments for message groups 10-35 and 36-50 become acknowledgments for message groups 10-50. This allows multiple acknowledgments to be represented in a single message.

The structure of the acknowledgment message is as follows.
struct sAckMsg [
integer uiFirstAckedMessageID;
integer uiLastAckedMessageID;
]

  Acknowledgment (ACK) is processed in the same way as TCP / IP. If a sent message is not acknowledged within a multiple of the average ACK time of a message sent to the same “selected destination”, the message is retransmitted.

  Messages are stored on the node from which the EUS generated them until acknowledged. This allows messages to be retransmitted if they are lost during transmission.

  If the network notifies Node B that queue A1 is no longer visible, Node B removes queue B1 from the network and frees all buffers associated with the communication. If the network informs node A that queue B1 is no longer visible, node A deletes queue A1.

  This only occurs if all possible paths between node A and node B have been deleted or if one or both of the nodes decides to terminate communication.

  If messages are not acknowledged by node B in time (via acknowledgment messages in queue A1), node A resends those messages.

Node B can increase or decrease the “reorder” buffer size at any point in time and notifies Node A of the new size by a message to queue A1. Node B changes size according to the amount of data that can be allocated to individual queues. The amount of data that can be allocated to individual queues depends on:
1. How much memory the node has.
2. How many queues the node remembers.
3. How many data flows are passing through the node.
4). How many queues originate from this node

The resize message is as follows:
struct sResizeReOrderBuffer [
// since messages can arrive out of order,
// the version number will help the sending
// node determine the most recent
// 'ResizeReorderBuffer'.
integer uiVersion;
// the size of the buffer
integer uiNewReOrderSize;
]

  There is also a buffer on the transmitting side (node A). The size of the buffer is controlled by system software running on the node. It is always less than or equal to the maximum window size provided by Node B.

A node node in a data stream is considered in the data stream if it is on the path of data flowing between the final sender and the final receiver. The node knows that it is in the data stream because the directly connected node tells it that it is in the data stream.

  Data may flow through nodes that are not labeled as in the data stream. Only nodes that are labeled as “in the data stream” are considered to be in the data stream. Nodes that have data flowing there but are not labeled as in the data stream are considered not in the data stream.

  The first node that tells another node that it is “in the data stream” is the node that has the EUS trying to send the message to that particular queue. For example, if node B wants to send a message to queue A1, node B becomes the first node to tell another node that it is “in the data stream” towards queue A1. The nodes send them to a queue, such as queue B, without labeling them “in the data stream”.

  A node in a data stream destined for a particular queue tells all nodes that are its “selected destination” for that queue that they are in the data stream destined for that queue. If all nodes that have told the node that it is in the data stream tell the node that it is no longer in the data stream, the node will send to all its "selected destinations" Tell them that they are no longer in the data stream.

  Basically, if a node is no longer in the data stream, it tells all nodes that it has as the selected destination that they are not in the data stream.

  This is useful for two purposes. First, it allows the nodes in the data stream to immediately try to find a better path. Second, it ensures that the nodes in the data stream do not “lost” the queue.

The structure used to tell another node that it is in the data stream is as follows:
struct sDataStream [

// the name of the queue, this could be replace with a
// number that maps to the queue name. (discussed later)
sQName qnName;

// true if now in the stream, false if not.
bool bInDataStream;

];

  Only data streams destined for type B1 queues have the ability to generate combined multipath paths. Type A1 queues in the data stream can be limited to a single path if necessary because the ACK messages are small and easily merged together. Type B nodes are never labeled as “in the data stream”.

  A possible enhancement is to GUID probe it to make sure that each node being added to the “data stream” does not form a loop (GUID probe is defined later).

A node task node communicates with a directly connected node to send a message generated by an EUS to another EUS. The node also sends a message that is used to establish and maintain a reliable communication with another EUS.

To send a message, the node
1. Where to send the message,
2. When to send a message,
Must be determined.

  Each of these cases is discussed in the following sections.

Where the message is sent The node decides where to send the message,
1. Provide the best latency for the final destination,
2. Without introducing "loop"
3. Attempts to select a connection node with enough transmission capacity.

When an initial queue knowledge queue is created by the EUS, the system needs a way to tell every node in the network that the queue exists, and every node goes to that queue through other nodes. Need a route. The goal is to recognize the queue and create a loop-free path.

When the EUS first creates a queue, the node on which the queue was created tells all directly connected nodes:
1. Queue name This is a unique name for this queue. Two independently generated queues must never have the same name.
2. Waiting time explained earlier. This is a value, expressed in seconds, that represents how long it takes for the message to travel from that node to the final destination node.
3. “Not enough capacity” status Explained later. This is a Boolean value that is true if any node in the route of the selected destination of this node cannot process more data flows than it is already processing.
4). Update latency will be explained later. This is a value, expressed in seconds, that represents the maximum time it takes for the latency update from the final receiver to reach this node.
5. The distance from the data stream is explained later. It is very similar to “update latency” except that it represents how far this node is from the node marked as in the data stream. This can be used to determine which queue is “more important”. An alternative implementation can have this represent how far the node is from the tagged data stream or from the node transmitting the payload message.

This update takes the following structure:
struct sQUpdate [

// the name of the queue. Can be replaced with
// a number (discussed later)
sQName qnName;

// the time it would take one message to travel
// from this node to ultimate receiver and be
// consumed by the EUS
float fLatency;

// if true, this node is already handling as
// much data as it can send. (discussed later)
bool bAtCapacity;

// the maximum time a latency update will
// take to travel from the ultimate receiver
// to this node. (discussed later)
float fUpdateLatency;

// calculated in a similar fashion
// to 'fUpdateLatency'. and records the distance
// from a marked data stream for this node.
float fLatencyFromStream ';
];

  Regardless of whether this is a previously unknown queue or an update to a known queue, the same information can be sent.

  Node update delayed transmission and node update ordering should follow the same approach as described above.

  If this is the first time the directly connected node has heard about the queue, the directly connected node will select the node that first communicated to it as its “selected destination” for messages to that queue. A node sends an EUS message / payload only to one or more nodes that are "selected destinations" even though other nodes have told it that they also provide a route to an EUS-generated queue To do.

If a node selects a directly connected node as a “selected destination”, it must tell the node that it has been selected as a “selected destination”. The structure of the message is as follows:
struct sPickedAsChosenDestination [

// the name of the queue. Could be replaced with a number
// (discussed later)
sQName qnName;

// true if the node this message is being sent to is a
// a chosen destination for this queue.
bool bSelected;

];

  A node will never select a node as a “selected destination” if another node already has this node as the “selected destination” for the queue. If this happens because both nodes selected each other at the same time, it needs to be resolved immediately.

  One approach is for both nodes to delete each other as the selected destination, wait for a random time, and then attempt to reselect each other.

  In this way, a network is created in which every node knows the EUS creation queue and has a non-loop path to the EUS queue through a series of directly connected nodes.

  FIG. 32 is a series of steps showing knowledge about queues propagating through the network. The linkages between nodes and the number of nodes in this figure are only examples, and in practice there are infinite diversity of linkages in any network topology, from any node to any number of nodes. Can exist.

  At any point in time, the nodes in the network do not attempt to gather global knowledge about the network topology or path. The system provides every node with the name of the EUS-generated queue and the latency that the directly connected node has given to the EUS-generated queue.

  Even though a node has multiple possible paths for a message, it only sends the message along one or more nodes selected as its “selected destination”.

  If a node selects another directly connected node as its “selected destination”, that node to avoid a loop that can be generated if two nodes select each other as a “selected destination” Tell about your choice.

  Every node keeps track of which queue it communicated to its directly connected nodes. Any new queue for which no directly connected node has been communicated is sent immediately (see Propagation Priority). For a fresh connection, the nodes on either side of the connection send knowledge about any queues they knew.

  If a node does not contain enough memory to store the name, latency, etc. of every queue in the network, it can “erase” a queue that appears to be unimportant. If this node is farthest from the tagged data stream, it will select those queues to remove from storage. The node uses the value “f LatencyFromStream” to determine how far this node is from the tagged data stream.

  An alternative embodiment may use the value “fLatencyFromStream” to represent the distance from the tagged data stream or from the node transmitting the payload packet.

  The only side effect of this is that you can no longer connect to those queues, and nodes that are totally dependent on that node for destinations will also be unable to connect to those queues.

  The value “fLatencyFromStream” can be used to help determine which queue is more important (see Propagation Priority). If a node is 100 seconds from the tagged data stream towards queue A and one second away from the tagged data stream towards queue B, this node is closest to the tagged data stream The node should select and store queue B, since it can be used more in helping to find alternative routes.

  A node that is told a new queue name with infinite latency (discussed later) ignores the queue name.

Queue Name Optimization and Messages Every queue update needs to have a way to identify which queue it refers to. Queue names tend to be easily long and are inefficient to send. Nodes can be made more efficient by using numbers to represent long names.

For example, if node A wants to tell node B about a queue named “THISALONGQUEUENAME.GUID” first,
1 = 'THISISALONGQUEUENAME.GUID'
To Node B.

The structure for this can be as follows.
struct sCreateQNameMapping [
int nNameSize;
char cQueueName [Size];
int nMappedNumber;
];

  Then, whenever node A wishes to send a queue update, node A can send a number representing the queue name instead of sending a long queue name. If Node A decides that it no longer wants to tell Node B about a queue called “THISISALGONGQUEUENAME.GUID”, it can instruct Node A to erase the memory for that mapping.

The structure is as follows.
struct sRemoveQNameMapping [
int nNameSize;
char cQueueName [Size];
int nMappedNumber;
];

Each node maintains its own internal mapping of which name is mapped to which number. Each node maintains a translation table so that names from directly connected nodes can be translated into its own naming scheme. For example, node A
1 = 'THISISALONGQUEUENAME.GUID'
Can be used.

Node B
632 = 'THISISALONGQUEUENAME.GUID'
Is used.

Thus, Node B has a mapping that allows it to translate Node A's numbering scheme into a numbering scheme that is understandable to Node B. In this example, it is as follows.

The use of this numbering scheme can also place messages from Node B to Node A into a queue towards them. For example, when the system has a message of 100 bytes, it reserves 4 bytes at the head for storing the queue name to which the message belongs, and the message follows. In this way, the total message size is 104 bytes. An example of this structure also includes the size of the message.
struct sMessage [
int uiQueueID;
int uiMsgSize;
char cMsg [uiMsgSize];
]

  When this message is received by the destination node, the node looks up its translation table to determine which queue this message should be placed on.

If a node on the path to the node from which the original queue was created is disconnected from the node it was using as its only "selected destination", the node First, try to find a non-loop alternate path.

  The node does this by examining all nodes that are not currently sending to this node (ie, having this node as the “selected destination”). Selecting a node that has this node as the “selected destination” creates a loop.

  This node uses the GUID probe to perform a loop investigation in the remaining possible nodes using the “GUID probe” process described later in “Adding Additional Paths”.

  If all potential alternative paths are loops, the node sets its latency to infinity and immediately informs all connected nodes about this new latency.

  If a node has a “selected destination” that communicated infinite latency to it, it immediately stops sending data to that node and removes the node from the “selected destination”. If all “selected destinations” have been deleted, the node sets its own latency to infinity and immediately communicates to its directly connected nodes.

  The node sets its wait time for the queue to infinity, communicates to its directly connected node and waits for a while (eg 1 second). When this period ends, the node immediately selects a directly connected node with no infinite waiting time as the selected destination and resumes data transmission.

  If a node does not find a suitable new source within twice the initial fixed time (eg 2 seconds) after the first period has elapsed, it deletes the message from that queue and Delete knowledge.

  This period is based on the multiple of the time it took for this node to send an update that made this queue infinite (see later propagation priority). This value is then multiplied by 10 or a reasonably large number depending on the network interconnectivity.

  For example, this number is greater than 10 if the network is very large and sparsely connected. In dense and well connected networks, this value is 10.

  If a node's latency moves from infinity to non-infinity, the node immediately tells all directly connected nodes about the new latency.

  In this example, in a network with 10 nodes, EUS created a queue at one of the nodes directly connected to the two nodes, one on each side of the network.

  In FIG. 33, every node in the network has just become aware of the EUS-generated queue (having zero latency in the lower right), and the numbers in each node are as defined above. Represents the waiting time in seconds.

  Next, in FIG. 34, one of the connections with the node having the EUS generation queue is deleted.

  A directly connected node that has lost a connection to a node that has an EUS-generated queue checks to see if any of the directly connected nodes are using it as a sender. Since all of them are, it is not necessary to probe them with a GUID to determine if they are looping. This node then sets itself to an infinite waiting time. This is illustrated in FIG.

This node immediately tells all directly connected nodes about the new latency.
If all of the “selected destinations” of the nodes are infinite, the latency of those nodes will be infinite as well. This is illustrated in FIG.

  This process continues until all nodes that can be set to infinity are set to infinity. This is illustrated in FIG.

  At this point, every node that is set to infinity stops for a period of time (eg, 1 second) and then selects the lowest latency destination it finds that is not infinity. This is illustrated in FIG.

  A node that was infinite immediately tells the node directly connected to it as soon as it becomes non-infinite. If one of those nodes is at infinity, the node selects the first connected node that gave it a non-infinite latency as its selected destination. This is illustrated in FIG.

  At this point, the network connection is reconfigured to allow transfer of all messages addressed to the EUS-generated queue to that queue.

  If a node's latency for a queue is infinite for longer than a few seconds, it can be assumed that there is no other alternative route to the final recipient, and any messages in the queue Can be deleted along with knowledge about the queue.

  FIG. 40 shows an overview of the above process.

Convergence nodes to the best path for nodes that are not in the data stream are always trying to reduce their latency to the first generated queue by selecting different selected destinations .

  Only the queues established on the node between the final sender and final receiver to forward EUS messages use the combined multiple paths to increase bandwidth. The ultimate sender marks this path by telling all “selected destinations” that they are in this data transmission path (“in the data stream”). Each of those “selected destination” nodes tells their own “selected destination” node that they are also “in the data stream”. FIG. 42 illustrates this.

  If all senders to a particular node are disconnected, or tell the node that it is no longer "in the data stream", or tell the node that it is "in the data stream" If the node tells the node that it is no longer a “selected destination”, the node clears the “in data stream” flag and all the selected destinations are no longer in the data stream. Communicate what's not there.

  A node that is currently in the path of an EUS message uses a different mechanism to select a new “selected destination” when forwarding between two nodes that have EUS.

  When a node with multiple selected destinations is deleted from the data stream, it deletes all selected destinations except the one with the lowest latency. This allows the mechanism to remain effective since the mechanism to find the loop will only be for one selected destination.

  A node that is not currently in the data stream always attempts to improve its latency to the final receiver by selecting a node that has a latency lower than the currently selected destination.

  When a node tries to select a different “selected destination”, it needs to make sure that it does not introduce a loop.

  The node trying to improve the performance of the connection prefers a node with no “capacity margin” (described later) over a node with “no capacity margin”, regardless of the waiting time.

  If a node is not currently in the EUS message / payload path, it is not allowed to use the GUID or message to check to see if the possible new selected destination is a loop, This is because such a network can be quickly over-operated by these messages.

  Instead, such a node waits for a periodic and automatic latency update from that node and compares it to the current “selected destination” latency, thereby providing a potential option. Watch the waiting time.

  In situations where a potential new destination is selected that creates a loop, the main reason for the apparently lower latency is the data progress in the loop between the current node and this potential new node. Is a delay introduced by.

  For example, if the current node's latency increases by 1 second per second and there is a loop with a 3 second delay between this node and the new potential “selected destination”, the new potential “ The “selected destination” always appears to have a latency of 3 seconds less than the currently selected destination.

  FIG. 43 is another example of a potential loop that should be avoided.

  If the current node selects this clearly “better option”, it creates a loop in the system.

  This is the case when the “fUpdateLatency” value from the queue update is used. This number is the maximum time it takes for a queue update to proceed from the node that created the queue. The actual calculation of this value will be explained later.

In the previous diagram, Node B attempts to determine whether Node F is a better option than Node A. Node B compares the difference in “fUpdateLatency” between node F and node A. In this example, the two values are as follows:
Node A fUpdateLatency: 8s
Node F fUpdateLatency: 13s

  Node A is the currently selected destination, and Node F's "fUpdateLatency" is higher than Node A's "fUpdateLatency", so Node B actually sends the message to Node B via a series of nodes. An inspection must be done to know if it will be transferred.

  Node B cannot immediately discard Node F as a valid new “selected destination” just because Node F has a higher “fUpdateLatency”. This is because the alternative route provided by node F can be faster because of congestion on the route provided by node A, even though it is a potentially longer route to the final destination. .

The basic idea behind passive loop testing is as follows.
The fUpdateLatency difference between A and F (5 seconds in this example) represents how long it takes for the latency update sent from Node B to reach Node F.
If there is a loop, the maximum waiting time from node F during this period is greater than the median waiting time from node A during the same period before this time.

  The total duration for the median should never be longer than the value of “fUpdateLatency” for node A. For example, if the difference between the “fUpdateLatency” values of the node A and the node F is 5 seconds and the “fUpdateLatency” of the node A is 8 seconds, the period for calculating the median is only 8 seconds. The period for monitoring the maximum value is 5 seconds.

  FIG. 44 illustrates this.

  This technique may show false positives for loops, but it is very rare to show false negatives. The handling of the loop will be described later.

Using the median in the above case is ideal, but to calculate the median, all observations need to be preserved. Shown below is a pseudo-code algorithm that can approximate the median and requires only a low fixed overhead.
float fPart1 = 0;
float fPart2 = 0;
int nCount = 0;
while (not done all observations) [

float fCurOb = GET_CURRENT_OBSERVATION ()
fPart1 = fPart1 + fCurOb;
nCount = nCount + 1;
fPart2 = fPart2 + abs (fPart1 / nCount-fCurOb);
]
float fCloseToMedian = fPart1 / nCount1-fPart2 / nCount;

  If the observation period is too small, they are rounded up to one iteration of the low resolution timer.

  During both the median and maximum observation periods, the value of fUpdateLatency can change. If the difference between the two “fUpdateLatency” increases, the new increased period is used. Lower values are ignored. This may result in a situation where the “median” period is less than the “maximum” period. This is good.

  If Node F's “fUpdateLatency” is less than Node A or smaller when performing the comparison, there may be no loop and the node may select Node F as the new selected destination without further delay. it can.

  If the queue on this node is “no capacity”, we prefer to select a node that has a higher latency and is not “no capacity”. This node still waits for an appropriate amount of time to confirm that this “capacity-prone” node remains with capacity. Even if the node under consideration changes to “no capacity” during this period, this node will use that node as the “selected destination” if it provides lower latency and does not introduce a loop. Can do.

  If this node is currently at infinity, this process is not used (see above).

  If a latency update greater than the median value of node A arrives from node F during the “maximum value” period, the test ends with a loop. Node B does not wait for the entire “maximum value” period to expire. An exception to this is when this node is “no capacity margin” and the node being considered is not “no capacity margin”.

  A node that is not in the data stream can have only one selected destination for its queue, so when selecting a new selected destination, it stops using the old selected destination.

  When a node that is not in the data stream switches to the new selected destination, it records the difference between the “fUpdateLatency” of the currently selected destination and the “fUpdateLatency” of the new selected destination. This value is stored and used to help detect loops (discussed later).

Insufficient capacity check Each queue of each node also has a mechanism to detect when data is being transmitted or received without capacity. A queue on a node has a latency of data in the queue of, for example, over 6 time intervals.
max ([wait time for all selected destinations])-min ([wait time for all selected destinations])
When it exceeds, it is considered that there is not enough capacity. The time interval is the time at which every destination that can be sent sends a certain number of messages (eg 10), or a minimum period (eg twice the minimum granularity of the fast system timer), or at most another period ( For example, 6 seconds).

  It is important that enough time elapses during the time interval for the selected destination to have the opportunity to reduce the total amount of data in the queue to the lowest possible point. For example, if data flows in at 100 bytes per second and flows out at 500 bytes every 5 seconds, an absolute minimum time interval of 5 seconds is required.

  FIG. 45 is an example of the queue level and the lowest level within the time interval.

  If a node cannot reduce the queue latency to this level over this period, it is considered to have no capacity. If the node cannot do so, there is too much data flowing into the node and the data cannot be sent out almost as soon as it arrives.

  If a node has no capacity, it tells all the nodes to which it is connected. If all "selected destinations" for a queue on a node are labeled as "no capacity", the node will tell all its directly connected nodes that it is also no capacity .

  The “no capacity” update proceeds through the network simultaneously with the normal waiting time update. They do not replace the normal data flow (see sQueueUpdate above).

  As explained earlier, a node that is not in the data flow attempts to find a non-loop alternate path to replace the “selected destination” that is labeled “no capacity”. If a node is in the data stream, it will not attempt to delete the “no capacity” node as the “selected destination” because of its “no capacity” status, but only based on latency. Decide to delete the node.

Finding additional paths when capacity is not available Nodes that have capacity due to too much data flowing in, use direct connection nodes to create a list of all possible additional paths. Possible additional paths are the following nodes:
1. 1. Node with sufficient capacity 2. Node not transmitting to this node 3. Node that does not form a loop A node with a queue destination other than the querying node (ie, no loop is formed)

  For each of these possible paths, a node with no capacity creates a unique GUID. This GUID is sent to each possible path to test each path for loops. If a loop is detected, the route is discarded from the list of possible additional routes.

  Each GUID corresponding to a possible route is transmitted along the route to the next destination node. The node saves the GUID and forwards the GUID to all nodes it has as a “selected destination”. If the node selects a new node as the destination, the GUID is passed to the new node. The node revokes the GUID by commanding all “selected destinations” to remove the GUID from storage. If all nodes that ordered the node to remember the GUID ordered the node to stop storing the GUID, or that they were no longer selected as destinations or that they were disconnected If so, the GUID is revoked.

  FIG. 46 shows an example of this. In FIG. 46, a node with insufficient capacity knows that the selection was a bad selection when it finds a GUID that it has sent to an additional selected destination where it can.

  Similarly, the GUID sent to the selected route lists all the routes along which data can flow from that node.

  If a machine with insufficient capacity finds that one of the GUIDs it sends back from the node sending data to it, the node that sent the GUID forms part of the loop. And know that the possible path is removed from the options for resolving the “no capacity available” status. The GUID message consists of the GUID, the name of the queue in question, the “progress time”, and a note that instructs the node to store or remove this GUID.

  When a node is instructed to store or remove a GUID, it sends this message as soon as possible (see Propagation Priority). If the node has already found and processed this GUID message, it ignores it.

The GUID message has the following structure.
struct sGUIDProbe [

// could also be a number that represents this queue
// (discussed previously)
sQueueName qnQueueName;

// true if the node is supposed to remember this GUID
// false if its supposed to forget it.
bool bRememberGUID;

// the actual GUID
char cGUID [constant_Guid_Size];

// how far the GUID will travel (based on fUpdateLatency)
float fMaximumGUIDTravelTime;
];

  The progress time of the GUID is set as (for example) three times the difference between fLatencyUpdate of a node looking for a new route and fLatencyUpdate of a possible new route with sufficient capacity. Each time a node receives a GUID probe, it communicates its contribution to the fLatencyUpdate value from the fMaximumGUIDTraveTime time (instead of adding this value to fLatencyUpdate to make this value normal) before telling the directly connected node about this GUID probe. Subtract. If the contribution is subtracted from the fMaximumGUlDTTimeTime time and the value is less than 0, the GUID probe is not passed to any selected destination.

  The value to be subtracted is based on the time for round robin update of all queues of the same class as the queue on which this GUID probe is based (described later. ).

  A node that has no capacity will wait for at least its initial “fMaximumGULDTraveTime” to give the GUID the opportunity to go through the network and loop back to the “no capacity room” node if a loop exists. If that time has elapsed, all potential choices for which the GUID has not returned to the node are considered valid choices.

  A message is sent to the node indicating that it is the lowest latency, not “no capacity”, but a non-looped node and that it is now the “selected destination”. This is done to prevent two directly connected nodes from selecting themselves as destinations and forming a loop.

  If two directly connected nodes select each other as destinations at the same time, both nodes immediately switch back to the previous destination and try the process of finding additional destinations again. Since the GUID mechanism includes a random interval, the likelihood that two nodes will select each other again decreases dramatically with each iteration.

  If all possible paths come back as a loop, the “no capacity room” node deletes the GUID. If this node is still “no capacity” after a while, it re-executes the process of searching for an alternative route. This node waits (for example) three times the maximum “fMaximumGUIDTraveTime” used in the last round of the GUID probe.

Even if the node has several options for where to send data, the maximum latency allowed for the queue is still
max ([wait time for all selected destinations])-min ([wait time for all selected destinations])
And depends on the memory available on that node. As soon as this new node is selected, the node can clear its “capacity free” status.

  This maximum value is not a strict limit, as there may be a flow control quota that allows more data to be transmitted (see Flow Control).

  Each time a token update is sent to the node sending data to this node, the current minimum latency in the last time interval and the “no capacity available” flag are sent as well. This makes it possible to have current latency data that allows the sending node to always select the best path.

Nodes that are not in the data stream that delete unused additional paths have only one selected destination, so they do not delete additional sources, but instead switch from one source to a better source (previous Explained).

  The node in the data stream is the only node given the possibility to develop multiple data paths (as described above).

  If a node in the data stream does not use a particular “selected destination” to transmit data for a period of time, it removes this selected destination from the list of selected destinations and Signals that it is no longer the selected destination.

  By telling the node that it is no longer the selected destination, the "in data stream" flag is also removed unless another node in "in the data stream" has also selected this node as the selected destination Is done.

  The certain amount of time to wait before deleting unused selected destinations should be relatively long compared to the time required to initially create a connection. The time for which the selected destination is retained can also be adjusted dynamically over time based on how much time has elapsed between the node being deleted and re-added.

A node that decides when to add / remove a selected destination if it is not “no capacity” must always have at least one “selected destination” if there are possible choices. (If there is no option, the waiting time is infinite).

  A node can have more than one “selected destination” if it is in the data stream for a particular queue, if that queue is the queue used to transfer data. In the TCP / IP handshake example, this is queue B1 (the previous figure).

  All "selected destinations" if the node is unable to delete "selected destinations" because it has enough capacity and all "selected destinations" are too active to delete (see above) Attempts to add a new selected destination that has a latency that is less than the highest latency.

  The node must select only possible “selected destinations” that are not “no capacity”.

  The node does this in the hope of replacing the current “selected destination” with a better option. This allows the node to make the entire path faster and require fewer buffers for messages passing through the node.

  The node probes possible options using the GUID probe (described above). If the GUID probe fails (a loop is detected), the node will select the next directly connected node with the next lowest latency when it next tries to optimize this connection.

  FIG. 47 is a flowchart illustrating this process.

If loops are accidentally created at nodes that are not part of a tagged data stream that resolves the accidentally created loops, their latency and “fUpdateLatency” are increased.

  FIG. 48 shows a loop that was accidentally generated at a node that is not in the data stream.

  Loops in nodes that are not in the data stream are rare because of the way we compare the possible new selected destination latencies (see above).

  We actively use the GUID to look for loops and probe possible new destinations, so that loops are not included in the data stream except as a result of routing changes being interfering after the GUID mechanism is used very rarely. Not generated.

  Simple loops that do not include “capacity free” nodes or nodes that have become infinite are easily resolved using standard “passive” loop detection mechanisms.

  The nodes in the loop appear as if they know about a queue that does not have an actual connection to the final receiver of that queue. For example, if a loop is maintained and the actual final receiver leaves the network, the loop will continue to self-maintain knowledge about this queue.

This problem occurs when:
1. The nodes in the loop are not “no capacity” and the nodes outside the loop are “no capacity”.
2. When a node outside the loop is "infinite".

  In either case, the solution is to detect the possibility of loops and change their latency to infinity in the same way as described above. As a result, the node is quickly moved to the non-loop state.

If we are on a node that is not in the data stream and there is a directly connected node such as
1. 1. When our node is not, it is in a “no capacity” state. Have infinite waiting time when we don't have

  The loop test is activated.

  During the process of selecting a new “selected destination”, the node records the difference between the “fUpdateLatency” of the new “selected destination” and the old “selected destination”. This time, expressed in seconds multiplied by 3, is called “possible loop time” (PLT).

  Our loop test begins by recording the minimum “fUpdateLatency”, “fLatencyFromStream”, and “fLatency” during the PLT.

  To determine if a loop actually exists if all three recorded values ("fUpdateLatency", "fLatencyFromStream", and "fLatency") are smaller than the previous iteration in two consecutive iterations In addition, a GUID probe is used. The GUID probe (see above) is set to travel through the network for (for example) PLT × 5 time.

  If a loop is detected, the node that detected it becomes infinite in the same way as the “path to the queue to be deleted”.

  If the GUID probe fails, the node returns to the loop test described above.

  If this process is repeated three times, the node will be “infinite” anyway (see “Route to Deleted Queue”).

When deciding when to send a message and when to send a message, the node
1. Whether to have an area for storing messages,
2. In view of the latency of other directly connected nodes and the amount of data in this node's queue, determine whether to provide a latency to a useful destination.

Even if a node that sends only useful selected destinations selects multiple “selected destinations” to send the message, it does not mean that they are all used. The “selected destination” is the current waiting time for the data in the queue,
[Selected Destination Wait Time] -min ([Selected Destination Wait Time])
Only used when equal to or greater than.

  If the waiting time for the “selected destination” is x seconds longer than the minimum waiting time for all “selected destinations”, then x seconds of data will be saved before using the selected destination. Saved on the node.

  If the selected destination has a waiting time that exceeds the waiting time of the current queue (described above), we will tell us when that node's waiting time falls below the specified value. Has the option to send a message to the node asking to inform Asking a node to send an update at a constant value also causes the node to send the current waiting time.

  This solves the problem of quick updates needed to keep the sender informed about the latency on the receiver side.

Latency and “no capacity” updates are passed on both token updates (defined later) and continuous streams that are limited to not exceed X% of node-to-node bandwidth. Usually this number is 1-5%. The node cycles through all known available latencies in a round-robin fashion (see Propagation Priority). Other methods of determining what order or how often to send queue updates can also be used, for example:
1. Percentage change is used,
2. Specific class queue names are marked for more frequent updates,
3. To increase latency updates near the data stream, a “distance from data stream” counter is used.

  If a queue message has not been sent to a selected destination for a certain period of time, the selected destination is deleted from the list of selected destinations for that node. This period is at least an order of magnitude greater than the total time required to initially establish a destination. An adaptive approach can also be used (described above).

Flow control Each node uses various amounts of memory, primary, etc. used to support information about connections to other nodes and queues, such as message data, latency, GUID, selected destination, etc. It has RAM.

  An example of the necessary information for flow control is whether node A has node B as a message destination. It is important not to allow Node A to overoperate Node B with too much data.

  Flow control operates using a token mechanism. Node B gives node A a fixed number of tokens corresponding to the number of bytes that node A can transmit to node B. Node A is not allowed to transfer more bytes than this number. Node B can send more tokens to Node A if it has more space available and recognizes that Node A has only a few tokens.

  There are two levels of flow control. The first level is node-to-node flow control and the second level is queue-to-queue flow control. Node-to-node flow control is used to limit the total number of bytes of any data (queues and system messages) sent from node A to node B. Queue-to-queue flow control is used to limit the number of bytes that move from a Node A queue that has the same name to a Node B queue.

  For example, if a 10-byte queue message moves from node A to node B, node-to-node flow control requires 10 tokens, and even queue-to-queue flow control for that particular queue, Similarly, 10 tokens are required.

  When Node B initially grants a token to Node A, it limits the total number of remaining tokens to a small number as a starting state from which to begin adjusting to maximize throughput from Node A.

Node B knows that it does not give Node A a sufficiently high “token balance” limit when the following two conditions are met:
• Node A tells Node B that it has more messages to send but it cannot send because it has run out of tokens.
If Node B sends data, the destination accepts it, but Node B encounters a "no data to send" condition.

  If node A seeks a higher “token balance” limit, but node B has not reached the “no data to send” state, then node B will increase “ Wait for "no data to send" state.

  Node B always tries to keep Node A in a state with tokens, whatever the “token balance” limit. Node B keeps track of the number of tokens that Node B considers Node A to have by subtracting the size of the message it has seen from the number of tokens it has given Node A. Node B finds that Node A has fallen below 50% of the “balance limit” it has assigned to Node A, and sends more tokens to Node A if it can accept more data. Node B can give tokens to Node A up to 50% points at its discretion, but must operate at that point.

  Assigning additional tokens also affects an estimate based on information on the Node B side regarding the maximum number of tokens that Node A can use to transmit data.

  This number of tokens does not exceed the “token balance” limit when added to the estimate based on Node B information about the number of tokens that Node A has. This number may be smaller depending on the amount of data in the Node B queue (discussed later).

  For example, consider node A and node B that are negotiating so that node A can transmit to node B. FIG. 49 shows the current state.

Node B generates a default allocation number that it wishes to provide to Node A. Next, the node B transmits a message including the allocated number (the maximum difference between the current and the current) to the node A. The message also includes a version number that is incremented each time the maximum limit is changed. The message sent from node B to node A is as follows.
struct sQuotaUpdate [

// the version
unsigned integer uiVersion;

// the queue name or number (see previous)
sQNName qnName;

// how much additional quota is sent over
unsigned integer uiAdditionalQuota;

];

  If we tell us that node A wants to send more data, we do this so that node A does it only once every time we adjust the maximum limit. FIG. 50 shows the current state.

If node A wants to send a 5-byte message to node B, it does not have a sufficient quota. In that case, the node A transmits a message to the node B informing that “I want to transmit more”. Node A then sets “version that sought more at the end” to match the current version. This prevents node A from repeatedly seeking more allocations if node B does not respond to the initial request. This message looks like this:
struct sRequestMoreQuota [

// the queue name or number (see previous)
sQNName qnName;

];

  FIG. 51 shows this state.

  Node B increases Node A's maximum quota limit to 100 bytes if there is no data in its queue but it can send to the selected destination. Node B sends a new allocation number with a new version number. FIG. 52 shows this state.

  Node A now has enough quota to send a 5-byte message. When the message is sent, node A removes 5 bytes from the available quota. When the message is received by node B, node B removes 5 bytes from the current allocation number it considers node A to have. FIG. 53 shows this state.

  Messages can continue to flow until node A runs out of quota or there are no more messages to send. If the allocation number that node B thinks that node A has falls below 50 bytes, node B immediately transmits an allocation number update. A quota update that does not change the maximum limit does not cause a version increment. Quota updates for different queues can be piggy back, so if one quota update is “needed” to be sent, just the other quotas that need to be replenished Updates can also be sent at the same time. This reduces the occurrence of special messages that are transmitted only by including one allocation number update.

  In general, system messages can also be piggybacked with data messages to reduce their impact.

  The same approach to extending the “balance limit” for queue-to-queue flow control applies to node-to-node flow control.

  The “balance limit” is also continuously reduced by the system at a small but constant rate (eg 1% per second). This has become large in a high capacity environment, but is now in a low capacity environment and allows for automatic correction over time of an unnecessarily high “balance limit”. If this continuation shrinks too low the "balance limit" (more is requested if more tokens are requested and the receiving node encounters a "no data to send" condition) The mechanism detects this and increases the balance limit again.

When giving other nodes quotas for flow control transmission when there is not enough capacity , they are enough to move the receiving node to the “no capacity” state and if possible stay there It is important to be able to give a certain number of quotas.

  Each incoming data if the waiting time in the queue on the node exceeds (max ([waiting time of all selected destinations]) − min ([waiting time of all selected destinations])) Flows should not acquire more quota than their maximum “balance limit” over this maximum latency.

  This is accomplished by having an “overcapacity token count” variable added to the receiving flow control structure that records the number of bytes received from its source while the queue is overcapacity.

  This number is deducted from the “maximum balance limit” when the node becomes more capable of providing the sending node.

  If the waiting time of the queue is less than its maximum waiting time, the “overcapacity token count” variable is set to zero.

  When data is removed from the overcapacity queue, we collect the number of bytes removed and subtract the total number of bytes from all “overcapacity token count” variables greater than 0 as evenly as possible. It is important that the “overcapacity token count” is always equal to or greater than zero.

  For example, if 120 bytes are removed from the queue, there are 4 connections that place data in the queue, and their “overcapacity token count” is 0, 100, 20, 50, then we have Divide the number of bytes (120) by the number of “overcapacity token count” variables (3) greater than 0 to get 40. Since the lowest “overcapacity token count” variable is less than 40 (20), we subtract that number (20) from all “overcapacity token count” variables. As a result, the four variables become 0, 80, 0, 50, and 60 bytes are still left. We repeat this process and subtract 30 from the two remaining “overcapacity token count” variables to obtain 0, 50, 0, 20.

In flow control TCP / IP for EUS queues , window size selection is important. If the window size in TCP / IP is too small, the performance is impaired, and if it is too large, system resources are used up without improving performance.

  The present invention allows for rapid convergence to the best window size using a “send-side only” algorithm.

  Nodes that are part of the tagged data stream only buffer enough data to ensure that they can be transmitted at maximum speed. This means that even if there is gigabytes of data to be transmitted, only a relatively constant and small percentage is being transmitted at a given time.

  However, if there is gigabytes of data to send (instead of just one small message), much more paths are used to transfer that data. However, no matter how many paths are used, the total amount of data being transmitted does not exceed the buffer given to the final sender by the final receiver.

  The primary metric that a node uses to determine which node to send to is latency. If 1000 seconds of data remain to be transmitted, all paths with a latency to the destination of less than 1000 seconds should be considered. If there is a very small amount of data and the latency to send it is 10 ms, a very small number of paths (and the fastest one) are used to transfer the data.

  This allows the node to replenish as many or as few nodes as necessary to ensure the fastest data transfer. This technique allows us to implicitly increase bandwidth when needed by trading off latency that is not needed.

The amount of data being transmitted is also limited by the size of the buffer that the transmitting node can allocate to its queue. The best size for the send buffer is as follows:
Send buffer latency => Max (latency of all selected destinations)-Min (latency of all selected destinations)

  This means that if we can continue to add nodes to the selected destination list, we can continue to expand the final sender's transmit buffer.

  The node with the EUS sending the message will allow this send buffer to grow to the point that the EUS can keep the queue “free of capacity” (in the same way that flow control works). Should. This ensures that all “selected destinations” can be used as much as possible.

  At the final receiver, the received message is placed in a reorder buffer. Since the nodes can arrange these messages in order, the messages are moved to the queue that the EUS uses to remove the messages from the queue for processing. The size of this queue retrieval buffer is set in the same way as the queue buffer between nodes (described in the flow control).

  If the queue that the EUS uses to retrieve the message exceeds its maximum size, this node directly knows that it is “no capacity” and does not give more directly to the connected node. Tell the connection node. Since the ordered message from the reorder buffer is still placed in this queue used by the EUS, this node no longer gives the directly connected node the quota for this queue, so Incoming message flow to the reorder buffer is stopped.

  If the queue used by the EUS is completely empty and the directly connected node wants to send more messages to the node with the EUS, the maximum size of the queue used by the EUS is Expanded).

  The size of this queue is affected by downward pressure as well as the queue in flow control.

  The size of the reordering buffer has nothing to do with the number of messages (or number of bytes) that the queue used by the EUS can hold.

  If the receiving EUS stops processing the message completely, all nodes in the network will transition to “no capacity” for that queue and the final sender will be used immediately to send the message out to the network. No more quotas can be given.

In networks that are larger than the propagation priority , bandwidth limitations for control messages need to be used.

  We use several types of restrictions. The total “control” bandwidth should be limited to a percentage of the maximum bandwidth available for all data.

  Control messages are divided into two groups. These groups are individually bandwidth limited based on a percentage of the maximum bandwidth. Each directly connected node has its own version of these two groups.

For example, the minimum size can be 4K and 5% of the maximum bandwidth can be specified for each group. For a simple 10MB / s connection, this means 4K information packets = 4096 / (10MB / s x 0.05)
= 0.0819s
Means to send every.

  Therefore, in this connection, a control packet can be transmitted every 0.0819 s or about 12 times per second for each group.

  The percentages and transmitted block sizes are examples and can be varied by those skilled in the art to better meet their application requirements.

First Bandwidth Limit Group The first bandwidth limit group transmits the following message. The following messages should be concatenated together to fit the block size that the control message fits.
1. 1. Name-to-number mapping for queues required for subsequent messages 2. Standard flow control message 3. GUID probe 4. Tell the node if it is now a “selected destination” HSPP message 6. Initial queue knowledge / to the infinity of the HSPP queue / from infinity Initial queue knowledge / to non-HSPP queue infinity / from infinity

Second Bandwidth Limit Group The second group sends latency updates for the queue. The second group divides the queue into three groups and transmits each of these groups in a round-robin fashion interleaved with each other 1: 1: 1.

  The first two groups are created by ordering all the queues using the value of “fLatencyFromStream”. If the queue has multiple selected destinations, the “selected destination” with the lowest latency is used to determine which “fLatencyFromStream” value to use.

  The queues are arranged in ascending order in a manner similar to that previously described in the single path embodiment. The queue is split in two based on how many updates can be sent in half a second using the limited bandwidth. This ensures that the first group is frequently fully updated and the rest are still updated, but less frequently.

  The third group consists of queues where this node is in the data stream.

  Each latency update includes the value “fUpdateLatency”. This value “fUpdateLatency” is calculated separately for each of the queues in each of the three groups. This value is calculated as the time it takes to send all items in the group at once. This value is added to “fUpdateLatency” of the selected destination with the lowest “fLatency”.

  This value is also used when determining how far the GUID probe will travel.

  The time for transmitting each of the three groups should be continuously updated based on the current transmission rate.

  A queue can only be one member of these groups at a time. This is important, otherwise “fUpdateLatency” is difficult to calculate.

  “FLatencyFromStream” means that not all nodes in the data stream add the “fLatencyFromStream” value from another node when passing their “fLatencyFromStream” directly to the connected node, It is calculated in the same manner as “fUpdateLatency”.

  For example, if node A is in the data stream and the time taken to update the group to which a particular queue belongs is 3 seconds, node A knows that it is 3 seconds from the data stream all directly Tell the connection node. Alternatively, node A can tell all directly connected nodes that it is 0 seconds from the data stream.

  If the queue needs to transition from a high frequency update to a low frequency update, we change its reported “fUpdateLatency” latency number to match the low frequency group, but in fact it Keep the frequent group items for 3 update cycles before moving to the group.

  When a node learns of a new queue, it places that queue at the end of the list of queues to be updated in one of the three groups to which it belongs in the second group of restricted updates.

Possible applications The following are examples where the present invention can be used. These examples are not intended to limit the application of the present invention.
1. Used in communication networks that allow the network topology to take an unlimited structure.
2. Used in cell phone networks that do not require the current "cell" structure where mobile cell phones need to be handed off to the next communication tower.
3. Used in grid computing environments to help remove hot spots and deal with failed nodes.
4). Used by utilities with software available on all electrical devices that can be turned on or off from the central command center to achieve system load management.
5. Multiple interconnected CPUs to exchange messages for applications such as grid computing, mass storage, or supercomputing environments where applications are currently limited by the lack of flexible and dynamic message transfer capabilities Or used in computing that allows computers to be coupled.
6). Allows any soldier and any equipment at the battle site to always maintain communication in a continuously changing terrain structure, allowing the network to continue regardless of the elements removed, destroyed, or added Used in military applications.
7). Used to form a discrete network group isolated from or as a subset of a larger network that allows any group to form its own network at any time.
8). It is used in traffic management that allows vehicles with this software and communication functions to coordinate highway dialogue or highway traffic management functions for greater efficiency or safety.
9. Enables all traffic signals to communicate with the traffic management computer and each other for greater efficiency in managing traffic flow and traffic signals can be added or added to the system without requiring any software management of the system Used in traffic signal traffic management, which allows you to be deleted from the system.
10. Since every participant in the network can provide linkage to the entire network and the sum of resources, it can be a communications utility for a community or region that provides virtually unlimited capacity and backup resources. Used as “master network”.
11. Software is used to manage computing centers that add or remove machines and applications and manage and monitor the center without human intervention and without reducing or stopping operations while doing so.
12 Electrical energy that can be used to integrate power generation, transmission, and consumption, make decisions based on predetermined criteria, and act immediately to deal with normal changes and adverse events Used in the grid.
13. Used to enable remote computing by dynamically combining users and remote sites without human intervention.
14 Used in air traffic control by managing and linking aircraft, air traffic, and ground resources.
15. It is used to connect various communication technologies such as wireless, landline, satellite, computer, and onboard system to connect to the network.
16. Used to generate effective routes for physical delivery of goods to various destinations that can be dynamically changed for changing conditions such as traffic pattern changes, additions or deletions to route destinations.
17. It is used as a mathematical tool similar to biocomputing to solve a large number of simultaneous calculations, especially to find an accurate solution to a complex problem involving many criteria.

  The above-described embodiments of the present invention are intended as examples of the present invention and may be changed and modified by those skilled in the art without departing from the scope of the present invention as defined only by the appended claims. .

1 is a schematic diagram of a network according to an embodiment of the present invention. FIG. 5 is a flowchart illustrating a method for disseminating network knowledge according to an exemplary embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network illustrating execution of a step of the method of FIG. 2 according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a network according to another embodiment of the present invention. FIG. 3 is a schematic diagram of a network according to another embodiment of the present invention. FIG. 12 is another schematic diagram of the network of FIG. 11. FIG. 3 is a schematic diagram of a network according to another embodiment of the present invention. FIG. 3 is a schematic diagram of a network according to another embodiment of the present invention. FIG. 15 is another schematic diagram of the network of FIG. 14. FIG. 15 is another schematic diagram of the network of FIG. 14. FIG. 3 is a schematic diagram of a network according to another embodiment of the present invention. 5 is a flowchart illustrating a method for acquiring network knowledge according to another embodiment of the present invention. FIG. 3 is a schematic diagram of a network according to another embodiment of the present invention. 6 is a flowchart illustrating a method for exchanging information to establish a connection between nodes according to another embodiment of the present invention. 5 is a flowchart illustrating an initialization process of a method for establishing a connection between nodes according to another embodiment of the present invention. FIG. 6 is a schematic diagram of a network showing additive characteristics of accumulated link cost for a method of disseminating node knowledge according to another embodiment of the present invention. 6 is a flowchart illustrating a flow of node knowledge in a network for a method of spreading node knowledge according to an exemplary embodiment of the present invention. 6 is a flowchart illustrating a flow of node knowledge in a network for a method of spreading node knowledge according to an exemplary embodiment of the present invention. 6 is a flowchart illustrating a flow of node knowledge in a network for a method of spreading node knowledge according to an exemplary embodiment of the present invention. 6 is a flowchart illustrating a flow of node knowledge in a network for a method of spreading node knowledge according to an exemplary embodiment of the present invention. FIG. 2 is a schematic diagram of a network illustrating a method for detecting an isolated core according to an embodiment of the present invention. 6 is a flowchart illustrating a method for routing through a network that uses TCP / IP as an example of a protocol that may be emulated, according to an embodiment of the invention. 1 is a schematic diagram of a network showing a node A directly connected to a node B and a node C, a node C connected only to the node A, and a node B directly connected to four nodes C. FIG. 6 is a flowchart illustrating how service time on a queue can be calculated according to an embodiment of the present invention. FIG. 2 is a schematic diagram of a network showing a configuration of nodes and queues according to an embodiment of the present invention. FIG. 6 is a plurality of flowcharts illustrating a series of steps illustrating knowledge about a queue propagating through a network according to an embodiment of the present invention. 1 is a schematic diagram of a network showing a state in which every node of the network has just learned of an EUS-generated queue, according to one embodiment of the present invention. FIG. 34 is a schematic diagram of the network of FIG. 33 with one connection with a node having an EUS-generated queue removed. FIG. 34 is a schematic diagram of the network of FIG. 33 in which a directly connected node that has lost connection with a node having an EUS generation queue sets the waiting time to infinity. FIG. 34 is a schematic diagram of the network of FIG. 33 with all selected destinations of that node being infinite. FIG. 34 is a schematic diagram of the network of FIG. 33 with all nodes that can be set to infinity set to infinity. FIG. 34 is a schematic diagram of the network of FIG. 33 with every node set to infinity stopped for a period of time and then selected the lowest latency it found that was not infinity. It is the schematic of the network of FIG. 33 which the node which was infinite became non-infinite and immediately transmitted to the directly connected node. FIG. 40 is a flow chart showing the incoming call waiting time update as outlined in the schematic diagrams of FIGS. It is the flowchart which showed the waiting time which is infinite. FIG. 2 is a schematic diagram of a network showing a data stream on a node between a final sender and a final receiver. 1 is a schematic diagram of a network showing an example of a potential loop to be avoided. FIG. It is the figure which showed the chart which compared the waiting time median value over a certain period with the waiting time maximum value over another period. FIG. 6 is a graph showing the number of bytes of data in a queue over time and the minimum queue level within a time interval. FIG. 6 is a schematic diagram of a network showing how a node with insufficient capacity finds that the selection was a bad choice when it finds a GUID sent to an additional selected destination where it can. 10 is a flowchart illustrating a method for determining when to add / delete a selected destination when it is not “no capacity”. 1 is a schematic diagram of a network showing a loop that was accidentally generated at a node that is not in a data stream. FIG. 2 is a schematic diagram of a network showing Node A and Node B that negotiate so that Node A can transmit to Node B. FIG. 1 is a schematic diagram of a network showing how node A notifies that it wants to send more data. FIG. FIG. 3 is a schematic diagram of a network showing how two nodes can negotiate message transfer when the number of assignments is limited. FIG. 3 is a schematic diagram of a network showing how two nodes can negotiate message transfer when the number of assignments is limited. FIG. 3 is a schematic diagram of a network showing how two nodes can negotiate message transfer when the number of assignments is limited. FIG. 6 is a schematic diagram of a network showing the best next step for each node to reach the core and the same network relocated to better show the hierarchy generated by this process.

Claims (40)

A self-organizing network,
(A) a plurality of nodes;
(B) at least one link interconnecting adjacent nodes of the nodes;
(C) each of the nodes is operable to maintain information about each of the other nodes present in the first partition of the node, the information comprising:
(I) first identification information indicating another node in the first partition;
(Ii) for each first identification information, second identification information representing an adjacent node, which is a desirable step for reaching the another node corresponding to the first identification information,
(D) a third representing each neighboring node which is a desirable step for sending a request for information about the node in a second partition not included in the first partition; A self-organizing network that is operable to hold identity information.   The network according to claim 1, wherein the third identification information is determined based on which of the adjacent nodes appears most frequently in each of the second identification information.   The network according to claim 1 or 2, wherein each of said nodes is operable to exchange said information with its neighboring nodes.   The network according to any of claims 1 to 3, wherein the at least one link has a set of service characteristics such that any path between two of the nodes has a set of cumulative service characteristics. .   5. The network of claim 4, wherein the information includes the cumulative set, and the desirable step associated with the second identification information is based on which of the paths has a desirable set of cumulative service characteristics.   The network according to claim 4 or 5, wherein the service characteristics include at least one of bandwidth, latency, and bit error rate.   The network according to claim 1, wherein the node is at least one of a computer, a telephone, a sensor, and a portable information terminal.   The network according to claim 1, wherein at least one of the links is based on a wireless connection. 9. The information according to any of claims 1 to 8 , wherein the information includes, for each of the first identification information, a value representing a distance to a labeled data stream toward the node associated with the first identification information. The described network. The network according to claim 9 , wherein nodes associated with the first identification information are ranked in ascending order increasing according to the distance, and the instructions are delivered to those nodes according to the rank. The network according to any one of claims 1 to 9 , wherein a network core is formed between neighboring nodes determined to be desirable steps for discovering the nodes that are within the second partition. The network of claim 11 , wherein each of the nodes is operable to deliver instructions to other nodes between the core and itself to maintain information about itself. Network according to any one of claims 1 to 12, comprising at least 2000 nodes interconnected by a plurality of links. Network according to any one of claims 1 to 12, comprising at least 5000 nodes interconnected by a plurality of links. Network according to any one of claims 1 to 12, comprising at least 10000 of nodes interconnected by a plurality of links. Network according to any one of claims 1 to 12, comprising at least 100,000 nodes interconnected by a plurality of links. A node used in a self-organizing network having a plurality of other nodes and at least one link interconnecting adjacent nodes of the nodes,
(A) including a computing device operable to maintain information about each of the other nodes present in a first partition of all of the other nodes, the information comprising:
(I) first identification information indicating another node in the first partition;
(Ii) each of the first identification information includes second identification information representing an adjacent node, which is a desirable step for reaching another node corresponding to the first identification information;
(B) a third representing an adjacent node, which is a desirable step for transmitting a request for information about the node in a second partition that is not included in the first partition; A node that is operable to hold the identity information of Executed on or for a node forming part of a self-organizing network having a plurality of other nodes and at least one link interconnecting neighboring nodes of said nodes A computer readable medium for storing a set of program instructions, wherein the program instructions reside on a computing device in the node and the other present in a first partition of all of the other nodes. For holding information about each of the nodes, said information being
(I) first identification information indicating another node in the first partition;
(Ii) for each of the first identification information, including second identification information representing an adjacent node that is a desirable step for reaching the other node corresponding to the first identification information;
The program instructions further represent an adjacent node that is a desirable step for sending to the computing device a request for information about the node in a second partition that is not included in the first partition. A computer readable medium for holding third identification information.   The computer-readable medium of claim 18, wherein the third identification information is determined based on which of the adjacent nodes most frequently appears in each of the second identification information.   20. The computer readable medium of claim 18 or 19, wherein each of the nodes is operable to exchange the information with its neighboring nodes.   21. A computer according to any of claims 18 to 20, wherein at least one of the links has a set of service characteristics such that any path between two of the nodes has a set of cumulative service characteristics. A readable medium.   The computer-readable medium of claim 21, wherein the information includes the cumulative set, and the desirable step associated with the second identification information is based on which of the paths has a desirable set of cumulative service characteristics.   23. The computer readable medium of claim 21 or 22, wherein the service characteristic includes bandwidth.   23. The computer readable medium of claim 21 or 22, wherein the service characteristic includes latency.   23. The computer readable medium of claim 21 or 22, wherein the service characteristic includes a bit error rate.   26. A computer readable medium according to any of claims 18 to 25, wherein the node is a computer.   26. A computer readable medium according to any of claims 18 to 25, wherein the node is a telephone.   The computer-readable medium according to any one of claims 18 to 25, wherein the node is a sensor.   The computer-readable medium according to any one of claims 18 to 25, wherein the node is a portable information terminal.   30. A computer readable medium according to any of claims 18 to 29, wherein at least one of the links is based on a wireless connection. 23. A method according to any of claims 18 to 22 , wherein the information includes, for each of the first identification information, a value representing a distance to a labeled data stream towards the node associated with the first identification information. The computer-readable medium described. 32. The computer-readable medium of claim 31 , wherein nodes associated with the first identification information are ranked in ascending order increasing according to the distance, and the instructions are delivered to those nodes according to the rank. The network core according to any one of claims 18 to 22 , or 31 , wherein a network core is formed between adjacent nodes that are determined to be desirable steps for discovering the nodes that are within the second partition. Computer readable medium. 34. The computer readable medium of claim 33 , wherein each of the nodes is operable to deliver instructions to other nodes between the core and itself to maintain information about itself. 30. A computer readable medium according to any of claims 18 to 29, wherein the self-organizing network comprises at least 2000 nodes interconnected by a plurality of links. 30. The computer readable medium of any of claims 18 to 29, wherein the self-organizing network includes at least 5000 nodes interconnected by a plurality of links. 30. A computer readable medium according to any of claims 18 to 29, wherein the self-organizing network comprises at least 10,000 nodes interconnected by a plurality of links. 30. A computer readable medium according to any of claims 18 to 29, wherein the self-organizing network comprises at least 100,000 nodes interconnected by a plurality of links. Apparatus using program instructions stored on a computer readable medium according to any of claims 18 to 38 . 7. A device comprising one of a device capable of utilizing instructions stored in a router, mobile phone, PDA, utility meter, vehicle, airplane, sensor, munitions, satellite, computer or other computer readable medium. 39. The apparatus according to 39 .

Images