Re: Patch: EMI UUCP DLR

"Nikos Balkanas" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <C0CA399832A840579EC3168AA0693365@drwho>
Yeap, but that's not DLR code. That's bb queue. It is not that difficult, 
though. Since this is all in the queue, it wouldn't delay processing of 
other SMS. Is it something desirable (delaying all subsequent MTs to the 
same destination from the same account)?

BR,
Nikos
----- Original Message ----- 
From: Konstantin Vayner
To: [email protected]
Cc: [email protected]
Sent: Thursday, June 24, 2010 6:38 PM
Subject: Re: Patch: EMI UUCP DLR


Actually, delaying a sequential message to same destination isnt such a bad 
idea because:
1) people cant read messages that fast
2) a lot of carriers have thresholds for destination addresses
3) if you have 1000 recipients with 10 messages to each , they will start 
getting messages faster if you throttle each one of them respectively 
(unless, of course, you have no speed limitations on carrier side)


Implementation isnt easy though, thats true


Regards,
Β Β Konstantin


On Thu, Jun 24, 2010 at 6:33 PM, Vincent CHAVANIS <[email protected]> 
wrote:


Le 24/06/2010 17:23, Nikos Balkanas a Γ©crit :


I see. But there is nothing you can do in such a case, so it is not an
issue. The patch attempts just to make things better for EMI, not worse.
Anyway, how frequent is that you get subsequenty pushes to the same dst
from the account?



For all services that need to send more than 1 messages to deliver the 
content
without using concatenated-messages.
Also for carriers, the "welcome messages" when you are in "roaming",
they are sending 3 msgs for the same dst. (imagine if you need to delay 1sec 
for each msg...)


Vincent.

-- 
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Direction du Developpement xMS+
http://www.telemaque.fr/
[email protected]

Tel : +33 4 92 90 99 84 (fax 9142)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.