Generic address structure for RIOT

Development archive
#1

Hi all,

I'm working on a FIB for RIOT, and have thought about providing a centralized managed generic address representation. It could solve the difficulty to provide a universal support to handle known addresses, like IPv[4|6], along with proprietary ones. A centralized managing of the generic addresses could enable to reduce multiple allocation for the same information shared by multiple contexts, e.g. a routing protocol and the FIB.

Hence, this introduces a management overhead for handling the generic addresses and for concurrent access. The question is if such approach is reasonable and beneficial for RIOT.

I'd be happy to hear your opinion about this.

I made a prototype implementation that shows a possibility for a generic address use. The specific files for the generic address can be found in [1] and [2].

Best regards, Martin

[1] https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/include/fib/generic_address.h [2] https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/generic_address.c

#2

Hi all,

I'm working on a FIB for RIOT, and have thought about providing a centralized managed generic address representation.

..

I made a prototype implementation that shows a possibility for a generic address use. The specific files for the generic address can be found in [1] and [2].

Seem to be heading in the right direction.

I'd only make one [positive] suggestion. In this day and age, it's too-late to be embedding all constants in the source code. I realise this is how software is often taught. The end result/implication is that network addresses will go in code, and to change them will imply a edit/build/deploy step.

What I'd like to suggest is putting a configuration file with every Riot-Application. Then have the network addressses stored in that. If you think about any IoT application, transmitting temperature, etc, destination and node addresses shouldn't need to be hardcoded.

For example:

project: house-temp-sensor (a directory)

Files:           house-temp-sensor.ini           house-temp-sensor.cpp           Makefile

--house-temp-sensor.ini---------------------------------------

[Node] name=garden-birdpond

[Access-Point] name=MYDSP-AP

#3

I’m with David, having a config file for each app would make life so much easier down the road. I’d especially like to a see a quasi-standards based format used. I’d suggest TOML which is essentially a formalized INI type config. While I haven’t personally used it I know that there’s an open source C implementation called libtoml that might be worth looking at.

#4

Adam Hunt <voxadam@gmail.com> writes:

house-temp-sensor.ini

Human-readable config files are great for systems you log in to.

Pekka Nikander has shown how to do this for very constrained devices: Just link in the config data, in binary (i.e., directly usable) form. This requires a couple more lines in the Makefile, but much less Flash for not-so-useful initialization code on the device.

If it needs to be a separate data item, use a format that you also use for communication, so you need only one parser on the device. That might be JSON for the larger (JSON+HTTP+TCP) nodes, or CBOR for the smaller ones (CBOR+CoAP+UDP). Neither is really that great for hand-editing (e.g., JSON doesn't have comments), so thats still a couple of lines in the Makefile. The source for the config can then be anything you have a Ruby/Python/Perl script for, even TOML.

Gruesse, Carsten