"Well, to get to the 15 Bytes transferred, I did not include the thousands of CPU cycles to create and pass those 15 bytes from bearerbox to smsbox. For someone with a GHz processor and lots of RAM, they don't care about the extras resources used. But, for us that have to support legacy systems running at 400Mhz with 128MB,....blah blah blah"
Is this for REAL ??? I have this picture of you guys, its like the 1960s or so huddled over those 24x80 green screens too.... thats why the code is so sqished up so you can fit as much on those poor 24x80 screeen....and minimal docos, no doxygen, no color syntax hi-lighting, you know it is 2005 now........ and none of the code looks like it would remotely pass a code review in a corporate environment like a bank,etc... it mostly looks very hackerish...... so theres my rant...i'm sure you'll try an shoot me now!! ----- Original Message ----- From: "Davy Chan" <[EMAIL PROTECTED]> To: "fred" <[EMAIL PROTECTED]> Cc: "devel" <[email protected]> Sent: Friday, February 11, 2005 3:25 AM Subject: Re: messageid DLR parameter -#- MailID:BEAA > **>From: "fred" <[EMAIL PROTECTED]> > **>To: "devel" <[email protected]> > **>Subject: Re: messageid DLR parameter > **>Date: Fri, 11 Feb 2005 01:09:27 +1100 > **> > **>----- Original Message ----- > **>From: "Davy Chan" <[EMAIL PROTECTED]> > **>To: "Matthew Hixson" <[EMAIL PROTECTED]> > **>Cc: "devel" <[email protected]> > **>Sent: Wednesday, February 09, 2005 7:04 PM > **>Subject: Re: messageid DLR parameter -#- MailID:PAAA > **> > **> > **>> > **>> 1) Not everyone needs a DLR for every SMS sent. > **>> 2) This solutions would force the SMS Msg struct passed back and forth > **>> between the bearerbox and the smsbox to increase in size with > **>> data that might not be relevant. > **> > **>well there is already dlr_url, which if you use for each message can add > **>quite a lot to the mesg size, > **>so complaining about adding more for this is invalid i think > > If you define the dlr_url and the dlr_mask, then there is a 100% chance > that the smsbox will use the dlr_url. But, there isn't a 100% chance that > the message-id will be used by the smsbox since the dlr_url might not > contain the escape code requesting inclusion of a message-id. > > How much size increase is it? In memory, the minimal an extra Octstr > declaration inside the SMS Msg struct takes one address reference pointer > (32-bits or 64-bits depending on your processor). If the Octstr is > fully occupied per SMPP v3.4, then the message-id will be 10 octets. > An Octstr struct consist of: > unsigned char *data; > long len; > long size; > int immutable; > Therefore, adding a fully occupied message-id to the SMS Msg struct in > a 32-bit CPU will be: > 11 Octets (message-id + 1 Octet for the '\0') > 4 Octets (pointer to the message-id) > 4 Octets (long len) > 4 Octets (long size) > + 4 Octets (int immutable) > --------------------------- > 27 Octets > > On a 64-bit CPU, the cost is even higher. > > Passing it from the bearerbox to the smsbox will cause > gateway/gw/msg.c:msg_pack() to compress the space requirement down to > 4 Octets (long size) > + 11 Octets (message-id + 1 Octet for the '\0') > ----------------------------------------------- > 15 Octets > > That's 15 bytes I pass from the bearbox to the smsbox that might > never be used if the dlr_url does not have the escape code for > a message-id expansion. > > ONLY 15 Bytes you say!!! What's the big deal? > > Well, to get to the 15 Bytes transferred, I did not include the thousands > of CPU cycles to create and pass those 15 bytes from bearerbox to smsbox. > For someone with a GHz processor and lots of RAM, they don't care about the > extras resources used. But, for us that have to support legacy systems > running at 400Mhz with 128MB, it does start to tax the system with each > extra addition to the SMS Msg struct. And, for us that have to support > Kannel in an embedded environment where our ARM7 CPU's are running at > 90Mhz with 64MB or RAM (spread between embedded Linux, SNMP, SIP stacks, > OpenSSL [Ouch!], and serial communication at 19,200 baud to a GSM modem), > that's really stressful! (Working on embedded systems really makes you > a much more cautious developer). > > **>> 3) This solution cannot be abstracted and used for all SMSC interfaces > **>> (unless all you want is the 'ts' field reported for every SMSC). > **> > **>we are talking about abstraction are we not ? so if an interface does not > **>inherently support a messageid, > **>or some means of referencing a mesg from the SMSC point of view, then then > **>its valid to be a void action > **>if the interface doesn't support it > > Actually, Kannel already has an abstraction of a reference returned by > the SMSC for each message submitted. This is the TimeStamp ('ts') field. > Each SMSC client implementation puts something different in this field. > For CIMD, EMI/UCP, Sema, it uses the TimeStamp as returned by the > SMSC. For AT it uses the counter returned from the +CMGS response. > For SMPP, it, luckily, is a unique message-id. > > But, can this 'ts' entry be used to uniquely match a DLR with an > SMS? No, because for some SMSC, the resolution of the 'ts' field > is in seconds and would fail if more than 1 SMS was sent to the > same destination address within the same second. > > **> > **>actually it might help if we list which ones DO NOT have a message id like > **>thing in the interface ? > **> > **>i just looked at SMASI for example, the Sequence, MsgReference, its kind of > **>the same thing, however instead > **>of being given the message ref by the other side (SMSC) the i/f tells the > **>SMSC what the ref is. > **>I still see it as the same concept? no ? yes ? > **> > **>we also have a HTTP interface - not using kannel tho - to a telco, it also > **>has a messageid thing - basically the > **>transaction no of the http get process.....so there... > > I, too, wrote something about the handling of the 'ts' for the different > SMSC client implementations. Check the mailing list. But, it still didn't > provide a complete solution. > > I'm not trying to start a flame war. But, I do think that things put > into the Kannel core should benefit all uses of Kannel equally. As > such, I try to provide as well-rounded a solution as possible. When > that fails, I'll provide a hacked solution but expect the votes to > be against me for inclusion into the source tree. > > See ya... > > d.c.
