> 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
