rfuchs at sipwise.com
Wed Jul 10 17:14:13 CEST 2013
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.
> 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
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.
More information about the sr-dev