rfuchs at sipwise.com
Wed Jul 10 21:50:34 CEST 2013
On 07/10/13 14:28, Daniel-Constantin Mierla wrote:
> It was not about 'do it yourself', but commodity for average users to
> deal with it ...
> It's again about existing tools/storage systems -- they have built-in to
> access json as an object/variable, no need to parse yourself and build a
> custom/own query language. Just for example, iirc, at some point I saw a
> patch/presentation that MariaDB can do optimized searching withing json
> object by matching with dedicated functions (as well as capability of
> setting just a value inside json docs).
> That will required development in all these systems, both can be seen as
> serialization mechanisms, but their structure is different, so existing
> json functions in one system cannot be reused.
> You implemented and it was your decision, so I don't have anything
> against using bencode in this case -- in the light of requests for
> comments you asked for, I tried to figure out if parsing faster bencoded
> strings pays off when balancing with the need to interact with/from
> different components in a complete operational platform.
I think all those cases that you mention are outside of the scope of a
control protocol between a SIP proxy and an RTP proxy. I don't see an
average user having much interest in the details of the protocol and
they probably wouldn't find the contents any more interesting if they
were in JSON format. Apart from that, there's no reason why an RTP proxy
shouldn't be able to export stats or what not via a different protocol
and/or in another format. But I don't think this specific protocol is
the place to think about interaction with other existing systems, since
those almost certainly wouldn't be able to speak the protocol anyway,
even if it uses JSON encoding, no matter how you design it. Unless you
go above and beyond and make it HTTP-based or some such...
Since you asked for specific numbers comparing the performance, here are
some. I took the "offer" command example from the mediaproxy-ng docs,
which isn't all that complex, with an average sized SDP body, and ran it
in a tight decode-encode-free loop. I increased the number of loop
iterations until I got a measurable run time. I did this for both the
bencode and the equivalent JSON representation, where the encode step
each encoded back to the original format. Using the json-c library, I
got a runtime of 18.9 seconds, while with bencode it runs in 2.3
seconds. This is further reduced to 1.6 seconds when the "print as
string" encoding step is skipped and the bencode representation instead
is put into an iovec array, which the rtpproxy-ng module does. In the
grand scheme of things this may or may not make a difference, but why go
slower if you can go faster...
Anyway, just my 2 bits worth.
More information about the sr-dev