miconda at gmail.com
Wed Jul 10 17:32:59 CEST 2013
On 7/10/13 5:14 PM, Richard Fuchs wrote:
> On 07/10/13 10:43, Daniel-Constantin Mierla wrote:
>> 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.
Are there pretty-printing tools for bencode? Or just 'gateways' to
>> 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.
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.
>> 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.
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:
This kind of operations makes very easy generating reports.
>> Another thing I haven't noticed is about brdiging between two networks
>> of the same type, are --ip/--ipv6 parameters taking values like rtpproxy
> 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.
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.
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
More information about the sr-dev