11 Jul
2013
11 Jul
'13
1:45 p.m.
On 7/10/13 9:50 PM, Richard Fuchs wrote:
On 07/10/13 14:28, Daniel-Constantin Mierla wrote:
My focus in the discussion was related to the query -- getting
statistics of the sessions, which can be very useful to humans. But also
I meant post-processing -- polling those statistics, save them to a
backend and then generate reports when needed.
Similar is the way we have the control protocol in kamailio, e.g.,
'kamctl stats' just displays what is sent back by kamailio.
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...
Going faster is good as long as the
overall impact is not actually
making the overall integration/system more complex.
Anyhow, I wanted to see if there were any strong technical arguments for
using bencode or just more like a preference.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda