Node Transactions and Node State

I am not excited about these ideas just now. (2012 Nov 28)

I explore here a design for node code that is organized around specifying:

Implicit in this is the notion of a queue of transaction requests that are produced by both the logic of other transactions, and external signals such as the arrival of a block of packets. Upon completion, transaction code will typically branch to a Done program which looks on the queue for the next transaction to do. Perhaps it is strategic for some transactions to directly initiate another—perhaps not. Perhaps there is more than one queue, depending on priority.

This level of design is above issues such as multiprocessing. It also is perhaps contrary to some issues of abstraction. We will see if we can gain the combined virtues of these two styles.

I have seen communications code gradually migrate to transaction style and I think it would have been better if the code had begun that way.

For now we describe a node that takes just one turn op from the steering information.


We first explain the major data structure without giving them names, nor enumerating their entire content.

Mutable State:

A fixed pool of fixed size buffers
Size = 64KB for now. Allocated at node boot. Buffer may be a bit bigger to hold data relevant to software or hardware error control. Also we may decide to carry 64KB payloads and then we need to leave room for the packet headers. Many buffers carry several, perhaps many packets. See this.
Next Buffer Link
A buffer can be on just one chain, depending on its own state and perhaps other things. Whether the link is next to the buffer is not yet decided. If not then both links and buffers form an array and are associated with other with a common array index. Perhaps this link is two ways for rapid removal.
A fixed set of physical interface control blocks.
Much detail to be filled in here.
A fixed set of logical interface control blocks.
This includes a link (or index) to a physical interface block. Two logical interfaces may refer to the same physical interface (fiber) but with different priority.
Circuits Table
An array of circuits, associated with each interface, indexed by the channel number in packets across that interface belong to some circuit thru the node.
Some transactions must wait until some arithmetic inequality or other simply computed boolean becomes true, and then it may be important to perform the transaction soon. Reference node code might, between transactions, poll the node state looking for these opportunities, but an efficient node code will test the inequality each time one of the operands changes.