This is useful for, as an example, actions which require multiple parameters.
A guarantee by the specific device that the variables are "local" ensures that
no race conditions occur, assuming the node isn't running two programs
accessing the same device (which should not be true on the basis that OC is
not generally a multitasking system)
The light node system should only be used where necessary, as light
nodes contribute absolutely nothing to network messaging.
Maybe a minified full port of culib could be made for a "medium node",
which would be (protocol behavior-wise) exactly like normal nodes,
but minified and with interfaces cut down internally.
The implementation in the oc/ subfolder of a hierarchial gateway goes
with the "allow subnets to cause higher-level broadcasts, and allow
higher levels to cause subnet broadcasts, but don't let messages leak"
solution
That is, the default if hierarchial gateways have no special
handling for broadcast addresses.
The tests assume a mesh network with known connections, the node doesn't,
so unneeded packet leakage isn't really as controllable as I'd hoped.
What's definitely important is that the system doesn't cache entries for
long enough that it starts continuously sending packets the wrong way
no matter what.
In practice it is unlikely that data that's too big for the reliability layer won't need splitting
anyway by the application at some point, and the libraries are already too open to OOM DoS.
The previous testcase was "all nodes communicating randomly", basically a worst-case.
This testcase is somewhat more realistic, a set of nodes communicating between each other via other
nodes, a given TO node recurring once every 5 seconds (approximately).
Notably, the 'packet transfer total' figure should be halved, as in the testcase pings and responses
are used, but only responses are counted.
20kdc
Skye
gamemanj