On 7/10/13 5:14 PM, Richard Fuchs wrote:
On 07/10/13 10:43, Daniel-Constantin Mierla wrote:
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.
Are there pretty-printing tools for bencode? Or just 'gateways' to json/xml pretty-printing.
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:
result.totals.input.rtp.bytes>1000
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 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.
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