[Interop-dev] RFC: add parameter link-type

Nemesis (spam-protected)
Sun Aug 30 13:38:33 CEST 2015


On 08/28/2015 02:06 PM, Henning Rogge wrote:
> On Thu, Aug 27, 2015 at 8:28 PM, Bastian Bittorf <(spam-protected)> wrote:
>> * Henning Rogge <(spam-protected)> [27.08.2015 19:20]:
>>> maybe we could add a "type" flag to the header of the NetworkGraph
>>> object that can be "link" or "node"...
>>>
>>> link data is link/interface specific, node data just cares about
>>> connections between nodes.
>> please write an example json.
> {
> "type": "NetworkGraph",
> "protocol": "olsr",
> "version": "0.6.6",
> "revision": "5031a799fcbe17f61d57e387bc3806de",
> "metric": "etx",
> "router_id": "172.16.40.24",
> "type": "node",

pay attention: type is repeated two times, which is not valid JSON.
At best the parser will ignore the first occurrence and use the second one,
at worst the parser will raise an exception and stop parsing.

> "nodes": [
>
> ...
>
> versus
>
> {
> "type": "NetworkGraph",
> "protocol": "olsr",
> "version": "0.6.6",
> "revision": "5031a799fcbe17f61d57e387bc3806de",
> "metric": "etx",
> "router_id": "172.16.40.24",
> "type": "link",

same here

> "nodes": [
>
>
> The first don't care about interfaces, just about routers and about
> edges that telling the code that the two routers are somehow connected
> by a single hop. You can get this kind of data from a single OLSR
> node.
>
> The second variant would have additional variables for the "edges"
> that announce the outgoing interface, maybe the mac address of the
> interface, and could even contain things like channel-frequency and
> bandwidth. You need to query this data from all over the mesh.

We definitely need something for local neighbour info, so we should open
an issue and keep discussing and experimenting.

I would like this object to be mostly compatible with NetworkGraph, if
possible.

Federico







More information about the Interop-dev mailing list