[B.A.T.M.A.N.] Alfred batadv-vis json conformance

[B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Andrew Lunn]

Hi Folks

I will soon need to parse the output of batadv-vis -f json.  However,
its not really, json, it does not pass json validation tools. Hence i
doubt i can use the standard parsing libraries.

There has been discussion similar to this recently, about alfred -r,
and a proposal to change the output to make it json conforming. I
would like to raise the discussion of modifying the vis output from
batadv-vis.

I have a simulation system of four nodes, fully interconnected, with
one double link, but is rather sort of translation table entries. The
current vis output is:

{ "primary" : "02:00:00:00:12:01" }
{ "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
{ "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" }
{ "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
{ "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5", "label" : "TT" }
{ "primary" : "02:00:00:30:10:01" }
{ "secondary" : "02:00:00:00:10:01", "of" : "02:00:00:30:10:01" }
{ "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" }
{ "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
{ "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
{ "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
{ "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e", "label" : "TT" }
{ "primary" : "02:00:00:00:11:01" }
{ "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
{ "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
{ "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
{ "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66", "label" : "TT" }
{ "primary" : "02:00:00:00:13:01" }
{ "secondary" : "02:00:00:30:13:01", "of" : "02:00:00:00:13:01" }
{ "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
{ "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
{ "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" }
{ "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
{ "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4", "label" : "TT" }

My first suggestion for a conforming output would be:  

[
  { "primary" : "02:00:00:00:12:01", 
    "neighbors" : [
        { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
        { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" },
        { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
    ],
    "TT" : [
      { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5" }
    ]
  },
  { "primary" : "02:00:00:30:10:01",
    "secondary" : [
       "02:00:00:00:10:01"
    ],
    "neighbors" : [
      { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" },
      { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
      { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" },
      { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
    ],
    "TT" : [
      { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e" }
    ]
  },
  { "primary" : "02:00:00:00:11:01",
    "neighbors" : [
      { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
      { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
      { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
    ],
    "TT" : [
      { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66" }
    ]
  },
  { "primary" : "02:00:00:00:13:01",
    "secondary" : [ 
      "02:00:00:30:13:01"
    ],
    "neighbors" : [
       { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
       { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
       { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" },
       { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
    ],
    "TT" : [
       { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" }
    ]
  }
]

I'm also wondering if label and gateway could have more meaningful
names? TQ and host? Also, is TT the best?

I would like suggestions and comments from others with more experience
with json. Is the basic structure O.K. Are there better names to use?

There is also the issue of can we change the format of the current
output. Is it considered an ABI? Should I add a third format string
which can be passed with -f to produce true json, and leave the old
format as is, for backward compatibility?

Thanks
	Andrew

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 6821 bytes --]

Hey Andrew,

On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
> Hi Folks
> 
> I will soon need to parse the output of batadv-vis -f json.  However,
> its not really, json, it does not pass json validation tools. Hence i
> doubt i can use the standard parsing libraries.

Yes, it is only JSON line-wise, but not the whole output. This output format
however is the same as we have/had in the batctl JSON output which comes
from the kernel (I think that was your contribution in the first place?).

Therefore I'd like to leave this old format as it is to allow communities
to seamlessly switch from batctl json vis to alfred-vis.

> 
> There has been discussion similar to this recently, about alfred -r,
> and a proposal to change the output to make it json conforming. I
> would like to raise the discussion of modifying the vis output from
> batadv-vis.

Regarding the other discussions, I'm still waiting for new patches from
Nils. ;)

I don't want to "parse" any transferred data in alfred, but we can do this
for tools like alfred-vis ... And yes, the default json output is
currently not JSON-compatible for binary data...
> 
> I have a simulation system of four nodes, fully interconnected, with
> one double link, but is rather sort of translation table entries. The
> current vis output is:
> 
> { "primary" : "02:00:00:00:12:01" }
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" }
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5", "label" : "TT" }
> { "primary" : "02:00:00:30:10:01" }
> { "secondary" : "02:00:00:00:10:01", "of" : "02:00:00:30:10:01" }
> { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" }
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e", "label" : "TT" }
> { "primary" : "02:00:00:00:11:01" }
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
> { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66", "label" : "TT" }
> { "primary" : "02:00:00:00:13:01" }
> { "secondary" : "02:00:00:30:13:01", "of" : "02:00:00:00:13:01" }
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
> { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" }
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4", "label" : "TT" }
> 
> My first suggestion for a conforming output would be:  
> 
> [
>   { "primary" : "02:00:00:00:12:01", 
>     "neighbors" : [
>         { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
>         { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" },
>         { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
>     ],
>     "TT" : [
>       { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5" }
>     ]
>   },
>   { "primary" : "02:00:00:30:10:01",
>     "secondary" : [
>        "02:00:00:00:10:01"
>     ],
>     "neighbors" : [
>       { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" },
>       { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
>       { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" },
>       { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
>     ],
>     "TT" : [
>       { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e" }
>     ]
>   },
>   { "primary" : "02:00:00:00:11:01",
>     "neighbors" : [
>       { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
>       { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
>       { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
>     ],
>     "TT" : [
>       { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66" }
>     ]
>   },
>   { "primary" : "02:00:00:00:13:01",
>     "secondary" : [ 
>       "02:00:00:30:13:01"
>     ],
>     "neighbors" : [
>        { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
>        { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
>        { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" },
>        { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
>     ],
>     "TT" : [
>        { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" }
>     ]
>   }
> ]
> 
> I'm also wondering if label and gateway could have more meaningful
> names? TQ and host? Also, is TT the best?

Hm, that is a good question. We also have the batman v with new metrics
coming up, I'm not sure how to handle these (maybe Antonio has some
idea?). It is not the TQ-value in the label after all, but some kind of
ETX-converted value (255/TQ if i remember correctly).

Maybe we can change the names to:
 * for neighbors: router->nexthop
 * TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?
> 
> I would like suggestions and comments from others with more experience
> with json. Is the basic structure O.K. Are there better names to use?
> 
> There is also the issue of can we change the format of the current
> output. Is it considered an ABI? Should I add a third format string
> which can be passed with -f to produce true json, and leave the old
> format as is, for backward compatibility?

As explained above, I'd like to keep the old format, so a third format
string should be used. It would be nice (if possible) to consider BATMAN V
at this point too to avoid adding many more formats in the future, but
generally I'm okay with adding new formats.

Thanks,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Andrew Lunn]

On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
> Hey Andrew,
> 
> On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
> > Hi Folks
> > 
> > I will soon need to parse the output of batadv-vis -f json.  However,
> > its not really, json, it does not pass json validation tools. Hence i
> > doubt i can use the standard parsing libraries.
> 
> Yes, it is only JSON line-wise, but not the whole output. This output format
> however is the same as we have/had in the batctl JSON output which comes
> from the kernel (I think that was your contribution in the first place?).
> 
> Therefore I'd like to leave this old format as it is to allow communities
> to seamlessly switch from batctl json vis to alfred-vis.

Hi Simon

That is what i was expecting. So when i did the first implementation
this morning, i added a new format, cjson, for conforming json. Not
the best of names, but i could not think of anything better.

> I don't want to "parse" any transferred data in alfred, but we can do this
> for tools like alfred-vis 

No parsing needed, its just needs new functions to print it. RFC patch
to come soon.

> >   { "primary" : "02:00:00:00:13:01",
> >     "secondary" : [ 
> >       "02:00:00:30:13:01"
> >     ],
> >     "neighbors" : [
> >        { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
> >        { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
> >        { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" },
> >        { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> >     ],
> >     "TT" : [
> >        { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" }
> >     ]
> >   }
> > ]
> > 
> > I'm also wondering if label and gateway could have more meaningful
> > names? TQ and host? Also, is TT the best?
> 
> Hm, that is a good question. We also have the batman v with new metrics
> coming up,

I've not been following BATMAN V too well. Is it metric, or metrics?
Can we simply change label to metric?

> Maybe we can change the names to:
>  * for neighbors: router->nexthop
>  * TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?

So here is what i have implemented.

# batadv-vis -f cjson 
[
  { "primary" : "02:00:00:00:12:01",
    "neighbors" : [
       { "router" : "02:00:00:00:12:01",
         "neighbor" : "02:00:00:00:10:01",
         "metric" : "1.000" },
       { "router" : "02:00:00:00:12:01",
         "neighbor" : "02:00:00:00:13:01",
         "metric" : "1.012" },
       { "router" : "02:00:00:00:12:01",
         "neighbor" : "02:00:00:00:11:01",
         "metric" : "1.000" }
    ],
    "clients" : [
       { "node" : "02:00:00:00:12:01",
         "client" : "8e:4c:88:c4:76:c5" }
    ]
  }
]

	Andrew

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
> > I'm also wondering if label and gateway could have more meaningful
> > names? TQ and host? Also, is TT the best?
> 
> Hm, that is a good question. We also have the batman v with new metrics
> coming up, I'm not sure how to handle these (maybe Antonio has some
> idea?). It is not the TQ-value in the label after all, but some kind of
> ETX-converted value (255/TQ if i remember correctly).

I think the ETX stuff comes from OLSR (but I don't know the details).

I agree with Simon that we should find a generic name (e.g. metric ?) but I am
not sure we can represent this value in a "algorithm-generic" fashion (and maybe
we don't want to).

> 
> Maybe we can change the names to:
>  * for neighbors: router->nexthop
>  * TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?

TT is specific to the mechanism we use to announce clients.
Moving to the generic "clients" could also be ok.

> > 
> > I would like suggestions and comments from others with more experience
> > with json. Is the basic structure O.K. Are there better names to use?
> > 
> > There is also the issue of can we change the format of the current
> > output. Is it considered an ABI? Should I add a third format string
> > which can be passed with -f to produce true json, and leave the old
> > format as is, for backward compatibility?
> 
> As explained above, I'd like to keep the old format, so a third format
> string should be used. It would be nice (if possible) to consider BATMAN V
> at this point too to avoid adding many more formats in the future, but
> generally I'm okay with adding new formats.
> 

I have to think about what batman v may require. But I don't see snything
special right now.

Cheers,


-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Martin Hundebøll]

On 2013-10-02 18:01, Antonio Quartulli wrote:
> On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
>>> > >I'm also wondering if label and gateway could have more meaningful
>>> > >names? TQ and host? Also, is TT the best?
>> >
>> >Hm, that is a good question. We also have the batman v with new metrics
>> >coming up, I'm not sure how to handle these (maybe Antonio has some
>> >idea?). It is not the TQ-value in the label after all, but some kind of
>> >ETX-converted value (255/TQ if i remember correctly).
> I think the ETX stuff comes from OLSR (but I don't know the details).
>
> I agree with Simon that we should find a generic name (e.g. metric ?) but I am
> not sure we can represent this value in a "algorithm-generic" fashion (and maybe
> we don't want to).

May I suggest that the cjson output includes an entry to tell the 
version of the batman-algorithm?

Users might want to do different map overlays (or whatever) depending on 
the available metric(s).

-- 
Kind Regards
Martin Hundebøll
Frederiks Allé 99, 1.th
8000 Aarhus C
Denmark

+45 61 65 54 61
martin@hundeboll.net

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Andrew Lunn]

On Thu, Oct 03, 2013 at 08:09:08AM +0200, Martin Hundebøll wrote:
> On 2013-10-02 18:01, Antonio Quartulli wrote:
> >On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
> >>>> >I'm also wondering if label and gateway could have more meaningful
> >>>> >names? TQ and host? Also, is TT the best?
> >>>
> >>>Hm, that is a good question. We also have the batman v with new metrics
> >>>coming up, I'm not sure how to handle these (maybe Antonio has some
> >>>idea?). It is not the TQ-value in the label after all, but some kind of
> >>>ETX-converted value (255/TQ if i remember correctly).
> >I think the ETX stuff comes from OLSR (but I don't know the details).
> >
> >I agree with Simon that we should find a generic name (e.g. metric ?) but I am
> >not sure we can represent this value in a "algorithm-generic" fashion (and maybe
> >we don't want to).
> 
> May I suggest that the cjson output includes an entry to tell the
> version of the batman-algorithm?
> 
> Users might want to do different map overlays (or whatever)
> depending on the available metric(s).
 
Hi Martin

I did think about that, but i'm not sure how. The cjson format is the
simple bit. I can add an outer layer with more key:value
pairs. Something like this:

batadv-vis -f cjson
{
  "algorithm" : 4,
  "source_version" : "2013.4.0-g6b13699",
  "vis" : [
    { "primary" : "fe:f0:00:00:04:01",
      "neighbors" : [
         { "router" : "fe:f0:00:00:04:01",
           "neighbor" : "fe:f0:00:00:05:01",
           "metric" : "1.000" },
         { "router" : "fe:f0:00:00:04:01",
           "neighbor" : "fe:f0:00:00:03:01",
           "metric" : "1.008" }
      ],
      "clients" : [
         "00:00:43:05:00:04",
         "fe:f1:00:00:04:01"
      ]
    },
...
  ]
}

But how do we determine the algorithm version? For the moment it can
simply be hard coded. But for version 5? Will the over-alfred format
change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for
algorithm 5?

Thanks
	Andrew

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On Thu, Oct 03, 2013 at 10:11:24AM +0200, Andrew Lunn wrote:
> > May I suggest that the cjson output includes an entry to tell the
> > version of the batman-algorithm?
> > 
> > Users might want to do different map overlays (or whatever)
> > depending on the available metric(s).
>  
> Hi Martin
> 
> I did think about that, but i'm not sure how. The cjson format is the
> simple bit. I can add an outer layer with more key:value
> pairs. Something like this:
> 
> batadv-vis -f cjson
> {
>   "algorithm" : 4,
>   "source_version" : "2013.4.0-g6b13699",
>   "vis" : [
>     { "primary" : "fe:f0:00:00:04:01",
>       "neighbors" : [
>          { "router" : "fe:f0:00:00:04:01",
>            "neighbor" : "fe:f0:00:00:05:01",
>            "metric" : "1.000" },
>          { "router" : "fe:f0:00:00:04:01",
>            "neighbor" : "fe:f0:00:00:03:01",
>            "metric" : "1.008" }
>       ],
>       "clients" : [
>          "00:00:43:05:00:04",
>          "fe:f1:00:00:04:01"
>       ]
>     },
> ...
>   ]
> }
> 
> But how do we determine the algorithm version? For the moment it can
> simply be hard coded. But for version 5? Will the over-alfred format
> change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for
> algorithm 5?

Good question. Maybe we don't really need to export the algorithm version?

In the end this information can be retrieved on the _same_ node where alfred (&
vis) is running by reading the "routing_algo" (sysfs-)file. And we can assume that the
entire network is running the same algorithm (otherwise neither alfred nor vis
would work as all the nodes must share the same routing algorithm).

What about the source version? How did you get it from the module?

Cheers,

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Andrew Lunn]

> > But how do we determine the algorithm version? For the moment it can
> > simply be hard coded. But for version 5? Will the over-alfred format
> > change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for
> > algorithm 5?
> 
> Good question. Maybe we don't really need to export the algorithm version?
> 
> In the end this information can be retrieved on the _same_ node where alfred (&
> vis) is running by reading the "routing_algo" (sysfs-)file.

No, that does not work. You can run alfred on a machine without
BATMAN. alfred --help says:

server mode options:
  -i, --interface             specify the interface to listen on
  -b                          specify the batman-adv interface configured on the system (default: bat0)
                              use 'none' to disable the batman-adv based best server selection

I'm using this "-i eth0 -b none" since my network topology has the
logger on a machine which is bridged into the mesh. 

> What about the source version? How did you get it from the module?

It is the alfred version, not the kernel module version.

   Andrew

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Thu, Oct 03, 2013 at 10:53:16AM +0200, Andrew Lunn wrote:
> > > But how do we determine the algorithm version? For the moment it can
> > > simply be hard coded. But for version 5? Will the over-alfred format
> > > change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for
> > > algorithm 5?
> > 
> > Good question. Maybe we don't really need to export the algorithm version?
> > 
> > In the end this information can be retrieved on the _same_ node where alfred (&
> > vis) is running by reading the "routing_algo" (sysfs-)file.
> 
> No, that does not work. You can run alfred on a machine without
> BATMAN. alfred --help says:
> 
> server mode options:
>   -i, --interface             specify the interface to listen on
>   -b                          specify the batman-adv interface configured on the system (default: bat0)
>                               use 'none' to disable the batman-adv based best server selection
> 
> I'm using this "-i eth0 -b none" since my network topology has the
> logger on a machine which is bridged into the mesh. 

Oh ok, I didn't think about this case.

> 
> > What about the source version? How did you get it from the module?
> 
> It is the alfred version, not the kernel module version.
> 

Ok (but I don't see how it can be useful)


Thanks!


-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Andrew Lunn]

> > > What about the source version? How did you get it from the module?
> > 
> > It is the alfred version, not the kernel module version.
> 
> Ok (but I don't see how it can be useful)

If for some reason we need to change the format in a none backwards
compatible way, it gives us a key we can use to determine what format
is in use.

It is just an idea, i've no strong preference.

   Andrew

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Nicolás Echániz]

El 02/10/13 15:36, Andrew Lunn escribió:
> On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
>> Hey Andrew,
>>
>> On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:

>> Yes, it is only JSON line-wise, but not the whole output. This output format
>> however is the same as we have/had in the batctl JSON output which comes
>> from the kernel (I think that was your contribution in the first place?).
>>
>> Therefore I'd like to leave this old format as it is to allow communities
>> to seamlessly switch from batctl json vis to alfred-vis.
> 
> That is what i was expecting. So when i did the first implementation
> this morning, i added a new format, cjson, for conforming json. Not
> the best of names, but i could not think of anything better.

maybe jsondoc would be more explicit, as it differentiates the output
from the current json(lines) format.


cheers,
Nico

Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

[Andrew Lunn]

On Sun, Oct 06, 2013 at 10:35:36AM +0200, Nicolás Echániz wrote:
> El 02/10/13 15:36, Andrew Lunn escribió:
> > On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
> >> Hey Andrew,
> >>
> >> On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
> 
> >> Yes, it is only JSON line-wise, but not the whole output. This output format
> >> however is the same as we have/had in the batctl JSON output which comes
> >> from the kernel (I think that was your contribution in the first place?).
> >>
> >> Therefore I'd like to leave this old format as it is to allow communities
> >> to seamlessly switch from batctl json vis to alfred-vis.
> > 
> > That is what i was expecting. So when i did the first implementation
> > this morning, i added a new format, cjson, for conforming json. Not
> > the best of names, but i could not think of anything better.
> 
> maybe jsondoc would be more explicit, as it differentiates the output
> from the current json(lines) format.

Hi Nico

Yes, i link it. Another patch version coming soon.

     Thanks
          Andrew