[asterisk-dev] [Code Review] 3977: RLS: Pre-allocate transmission data buffer to allow for sending of large NOTIFY requests.

Matt Jordan reviewboard at asterisk.org
Fri Sep 5 07:32:27 CDT 2014



> On Sept. 4, 2014, 3:49 p.m., Matt Jordan wrote:
> > This is a loaded question but... how much does 64k "buy" us? That is, how many different list elements can we typically embed in a 64k body?
> 
> Mark Michelson wrote:
>     The list used in the test on /r/3978/ has 20 presence resources. The full state NOTIFY takes up ~17500 bytes. So, extrapolating a bit, if you're subscribing to presence (with no Digium presence supplement), then I ballpark the maximum at ~70 resources. If you have a setup where you have a master list with embedded sublists, then the number goes down some, but not by much. If you had a top-level list with two approximately equal sublists, I'd reckon that with the extra RLMI body part, you'd maybe have to dock the estimate by a single resource, maybe two.
>     
>     MWI bodies are much smaller than presence bodies, so I'd estimate you could probably get about 5 times as many MWI resources as presence resources at 64K.
> 
> Mark Michelson wrote:
>     And just so we have some numbers here, I made a local change to the test to enable Digium presence, and the resulting full state NOTIFY now is ~19500 bytes. So with Digium presence, the estimate for number of presence resources drops to ~60 resources at 64K.

I'd say this approach makes sense.

I can see eventually wanting to break lists up into 64k chunks, each in their own NOTIFY request - although I'm not sure that's allowed, since you're no longer sending the full state in a single NOTIFY request.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3977/#review13241
-----------------------------------------------------------


On Sept. 4, 2014, 3:11 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3977/
> -----------------------------------------------------------
> 
> (Updated Sept. 4, 2014, 3:11 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24181
>     https://issues.asterisk.org/jira/browse/ASTERISK-24181
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When testing RLS with large lists, it was found that attempting to send a full state NOTIFY request would result in an error from PJSIP of PJSIP_EMSGTOOLONG. I've written in detail about the problem on the following wiki page: https://wiki.asterisk.org/wiki/display/AST/PJSIP+Large+Messages
> 
> On that page, I propose several solutions to the problem. The one presented in this review is based on the edit at the bottom of the wiki page. We get around the max message size of PJSIP by pre-allocating the transmission data buffer to be large enough to hold whatever message we need to send. This way, PJSIP happily writes the message to the buffer and sends it on.
> 
> There are a couple of questionable bits in this review:
> 1) Even though we are working around PJSIP's maximum message size limit, this patch imposes its own limit of 64000 bytes for the message. Should we perhaps make this limit smaller? Larger? Transport-dependent?
> 2) If we detect that the message is too large to be sent, we return an error when attempting to send the NOTIFY. However, I wonder if we should also just terminate the subscription as well.
> 
> 
> Diffs
> -----
> 
>   /branches/13/res/res_pjsip_pubsub.c 422576 
> 
> Diff: https://reviewboard.asterisk.org/r/3977/diff/
> 
> 
> Testing
> -------
> 
> See /r/3978 for a testsuite test that exercises this.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140905/efccaa93/attachment-0001.html>


More information about the asterisk-dev mailing list