The netgraph framework provides an unambiguous and simple to use method of specifically addressing any single node in the graph. The naming of a node is independent of its type, in that another node, or external component need not know anything about the nodes type in order to address it so as to send it a generic message type. Node and hook names should be chosen so as to make addresses meaningful.
Addresses are either absolute or relative. An absolute address begins with a node name or ID, followed by a colon, followed by a sequence of hook names separated by periods. This addresses the node reached by starting at the named node and following the specified sequence of hooks. A relative address includes only the sequence of hook names, implicitly starting hook traversal at the local node.
There are a couple of special possibilities for the node name. The name . (referred to as .:) always refers to the local node. Also, nodes that have no global name may be addressed by their ID numbers, by enclosing the hexadecimal representation of the ID number within the square brackets. Here are some examples of valid netgraph addresses:
The following set of nodes might be created for a site with a single physical frame relay line having two active logical DLCI channels, with RFC 1490 frames on DLCI 16 and PPP frames over DLCI 20:
[type SYNC ] [type FRAME] [type RFC1490]
[ "Frame1" ](uplink)<-->(data)[<un-named>](dlci16)<-->(mux)[<un-named> ]
[ A] [ B](dlci20)<---+ [C ]
| [ type PPP ]
One could always send a control message to node C from anywhere by using the name "Frame1:uplink.dlci16". In this case, node C would also be notified that the message reached it via its hook mux. Similarly, "Frame1:uplink.dlci20" could reliably be used to reach node D, and node A could refer to node B as ".:uplink", or simply "uplink". Conversely, B can refer to A as "data". The address "mux.data" could be used by both nodes C and D to address a message to node A.
Note that this is only for control messages. In each of these cases, where a relative addressing mode is used, the recipient is notified of the hook on which the message arrived, as well as the originating node. This allows the option of hop-by-hop distribution of messages and state information. Data messages are only routed one hop at a time, by specifying the departing hook, with each node making the next routing decision. So when B receives a frame on hook data, it decodes the frame relay header to determine the DLCI, and then forwards the unwrapped frame to either C or D.
In a similar way, flow control messages may be routed in the reverse direction to outgoing data. For example a ""buffer nearly full"" message from "Frame1:" would be passed to node B which might decide to send similar messages to both nodes C and D. The nodes would use "direct hook pointer" addressing to route the messages. The message may have travelled from "Frame1:" to B as a synchronous reply, saving time and cycles.
A similar graph might be used to represent multi-link PPP running over an ISDN line:
[ type BRI ](B1)<--->(link1)[ type MPP ]
[ "ISDN1" ](B2)<--->(link2)[ (no name) ]
+->(switch)[ type Q.921 ](term1)<---->(datalink)[ type Q.931 ]
[ (no name) ] [ (no name) ]
Structures are defined in
.In netgraph/netgraph.h (for kernel structures only of interest to nodes) and
.In netgraph/ng_message.h (for message definitions also of interest to user programs).
The two basic object types that are of interest to node authors are nodes and hooks. These two objects have the following properties that are also of interest to the node writers.