-
Notifications
You must be signed in to change notification settings - Fork 42
FAQ
The string format to print out DAGs is documented at Human readable XIP address format. From that page, one reads the following: The prefix "!" indicates that the address is invalid. Any index greater than 35 (i.e. 'z') is represented by '+', and an empty edge by '*'.
The function that tests if an address is valid or not checks many things as one can verify in the source code, for example, that the DAG is a single component, that there is no edge after an empty edge, the DAG is in topological order, etc.
This function assumes that addresses come from userland, so they cannot have chosen edges, and that is the reason most destination addresses in packets on a wire will be invalid. One may want to have a special version of this function for Wireshark, but nobody has worked on it yet.
Once an address is deemed invalid, all edges are printed out, including empty edges, in order to help with debugging cases like "-2**9", that is, an edge after an empty edge.
This question can arise when considering addresses like the following:
u4id-0a024702c3d70000000000000000000000000000-21: zf-0110000000000000000000000000000000000000-2: xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b-210
It appears as if the edges coming out of the last node of the DAG (the XDP) are directed toward the previous nodes, such as 0 (the U4ID), 1 (the zF), or 2 (the XDP itself). However, the last node of the DAG is a sink, meaning that it does not have any outgoing edges. The edges of the sink represent the edges of entry node.
This example can be found on the page An exemplifying demo, which includes a image of the DAG that may help you to understand what the textual representation above is trying to show. More information about the address grammar can be found on the page Human readable XIP address format.
In some cases, the source address DAG is the inverse of the destination address DAG, but this is not necessarily true. To new users of XIA, it is perhaps tempting to think of the DAGs as path specifications through the network, so it would only be natural to follow the reverse path back to the source. However, the DAG does not specify a path. The DAG is used to express an intent to the network, and typically the destination intent cannot be expressed in the same way as the source intent.
In a simple example, consider a client that wants to send a request to a server, and uses a destination DAG that looks like AD_1->HID_1->XDP_1 to do so. AD_1 identifies the server's administrative domain, HID_1 identifies the server, and XDP_1 identifies a socket listening on the server. When the server receives the request and goes to respond to it, notice that it would not make sense to send data back to the client through the reverse DAG, XDP_1->HID_1->AD_1, since none of this information is related to the cilent!
The original reasoning behind having such a large identifier space was two-fold. First, having a large address space would reduce the possibility of address space depletion. Since XIA must be able to address very large sets of entities, such as identifying globally-unique pieces of content, the address space must also be large. Second, XIDs typically are cryptographically secure identifiers, and a longer identifier is more secure than a shorter identifier.
It has also been discovered that XIDs can serve as data structures. For example, the zFilter principal uses the XID field as a Bloom filter. It has proven beneficial to have ample space to store information for these kinds of principals.
All grants that have generously supported the development of Linux XIA are listed on our Funding page.