10 Jul
2013
10 Jul
'13
6:32 p.m.
On 7/10/13 5:14 PM, Richard Fuchs wrote:
That's is indeed an inconvenience, although most of sdps don't have
quotes, a walk through has to be done to be safe. The impact might not
be that significant, though.
I was referring to post-processing -- i.e., do the queries periodically
or for each call at the end, store the results in a storage system and
then generate reports. With json, in some systems you can simply refer
to it as a structure, like:
result.totals.input.rtp.bytes>1000
This kind of operations makes very easy generating reports.
The question was ofr mediaproxy-ng app, because I was referring to
--ip/--ipv6 parameters -- wanted to see if it supports bridging networks
of same address family.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 07/10/13 10:43, Daniel-Constantin Mierla wrote:
Are there pretty-printing tools for bencode? Or just 'gateways' to
json/xml pretty-printing.
Hello,
I understand that the documentation of the protocol is exemplified with
JSON, but the implementation is actually bencode? From the readme it
seems you still keep the key=value format, passing them as a dictionary
in the control protocol. That means it could result in dictionaries
included in other dictionaries and/or lists (e.g., the result of query,
like the last json in the readme from the github) - obviously no longer
that easy to troubleshoot by 'eye'.
Correct, that's about the only disadvantage bencode has over JSON.
However, large JSON structures can also be quite cumbersome to read if
condensed enough, unless you run them through a pretty-printer (which,
btw, I had to do with that query example from the readme). The same
process applies to bencode structures. Have you got any figures of json vs bencode
performances that made you
mind to go for the later?
I don't. But since the primary purpose of the control protocol is to
pass back and forth SDP bodies, the fact that those don't have to be
copied and escaped/unescaped every time a request is sent or a reply
is received should give a clear advantage to bencode. From my point of view, json would have had the
benefits of being easy
to query/display in some languages as well as storage engines. This is
mainly for statistics, when willing to search for various situations,
without a need to pre-process the result from the rtp relay.
Assuming you're talking about searching in, or running stats over, the
raw encoded data blobs that occur on the wire, bencode actually makes
this easier, since the encoding is deterministic, i.e. there's only
one way to encode any particular structure or data. With JSON on the
other hand, the encoded version could look like anything and you'd
have to get into complicated regular expressions to get what you're
looking for, while still leaving a chance of missing it due to
unexpected escaping. Another thing I haven't noticed is about
brdiging between two networks
of the same type, are --ip/--ipv6 parameters taking values like rtpproxy
addr1/addr2?
Mediaproxy-ng currently only supports one address each for IPv4/6. But
this is not a limitation of the control protocol or the module, as it
still supports the same external/internal flags like the old one.