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
