[SR-Users] binrpc reply sizes

Daniel-Constantin Mierla miconda at gmail.com
Wed Oct 30 09:05:46 CET 2019


Hello,

the ctl module was developed by SER developers during 2005-2008, so I do
not have a first hand knowledge about its design, but based on past
experiences:

- binrpc_max_body_size - the max size expected for the entire rpc response

- binrpc_struct_max_body_size - the max size expected for one structure
in the rpc response

- binrpc_buffer_size - seems to be used for printf-like functions used
to build the rpc response

A structure in rpc response is enclosed between { ... } and can also
contain structures.

The ctl module uses system malloc by default for its internal buffers
related to rpc response, so it doesn't impact the allocated pkg memory.

It might be better to switch to jsonrpcs, which does dynamic allocation
for building rpc response (also using system malloc).

Cheers,
Daniel

On 29.10.19 01:32, Alex Balashov wrote:
> Hi,
>
> What is the relationship between the `ctl` modparams
> `binrpc_buffer_size`, `binrpc_max_body_size`, and 
> `binrpc_struct_max_body_size`?
>
> More especially, how interdependent are they? Is there a set of
> circumstances in which one would wish for the structure buffer to be
> smaller than the reply body buffer? What about the internal buffer? Is
> it used only for some kind of intermediate formatting, or does it also
> hold the entire reply in some aspect?
>
> The reasons for asking are predictable: RPC command 'dlg.list' throws
> out "reply too big" on some occasions, and rather than simply increasing
> all of these drastically, I would like to learn more about which ones it
> makes sense to increase, and in what proportion with respect to each
> other. I also think this idea should be more clearly developed in the
> documentation.
>
> Thanks,
>
> -- Alex
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com




More information about the sr-users mailing list