the reporting statistics should also report the number of queued message parts queued, very useful, believe me. Nice touch about timing out stranded msg parts,...I thought of it but never did anything about it, i think its extremely unlikely event, as i have seen message parts almost always sent consecutively from SMSC, this answers the question on performance somewhat too, the messages are not held in the queue(memory) for too long, even under heavy message load.
----- Original Message ----- From: "Alejandro Guerrieri" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, September 06, 2006 2:22 PM Subject: Re: [PATCH] concatenate incoming SMS prior to hand over to smsbox > Just a quick question: What are the performance implications of > keeping all those parts in memory? It may have some performance > penalties, specially under heavy traffic isn't it? > > IMHO this should be enabled/disabled from the config files. > > Besides that, it's a nice feature to have and I'd surely chose to have > it enabled. > > Regards, > > On 9/5/06, Alex Kinch <[EMAIL PROTECTED]> wrote: > > I'm not a C coder so can't comment on the way the patch works, but > > definitely +1 from me for adding this feature - it's long overdue IMHO > > and saves having to code something similar on the receiving script. > > > > Alex > > > > On 9/5/06, Paul Bagyenda <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > Attached is a proposal for addressing the above issue. Stipe and I > > > have had this discussion for a while, and I finally got round to > > > doing it. The main driver for this has been the need for Mbuni MMS > > > Gateway (www.mbuni.org), which uses Kannel's libs, to be able to > > > receive MMS notifications (for those users who have a GPRS/GSM modem, > > > rather than a full-blown MMSC connection). MMS notifications > > > typically span more than one SMS. > > > > > > The short of it is that with this patch applied: > > > - each incoming SMS is examined to determine if it is part of a > > > concatenated set (we look for the concatenate udh) > > > - if it is, we hold onto it and wait for other parts > > > - when all parts are received, we combine them and pass on the > > > message for further processing > > > - if after a reasonable interval (30 mins), we haven't seen the other > > > parts of a message, we throw the received parts away. > > > > > > All changes are localised to gw/bb_boxc.c so it should be reasonably > > > easy to check that nothing is broken. > > > > > > I have tested this with a live implementation, using both > > > concatenated plain text and a picture message (which has a longer > > > UDH), and it works nicely. Kindly review. > > > > > > Thanks > > > > > > Paul > > > > > > Ps. Also included is a previous patch, proposing some improvements to > > > my earlier improvements to the mime module. Generally these had to do > > > with reducing the amount of copying of objects. > > > > > > > > > > > > > > > > > > > -- > Alejandro Guerrieri > Magicom > http://www.magicom-bcn.net/ > LinkedIn: http://www.linkedin.com/in/aguerrieri >
