Hi, I believe you have not undestand correctly, what I tried to explain... Kannel does already what you talk about. That means if DLR where received from smsc then ack will be send immediately. If kannel does receive ack for the message,then next free window place will be used for next message. So I can not undestand, why it happens?
Can you please try, as workaround for this issue, to set window size in your config to (really_window_size - 1) and look what happens... Looking forward for your response... On Wednesday 06 August 2003 16:22, Holger Seiferth wrote: > Hi, > > sorry for the delayed response, I just checked the issue again. From my > point of view your description of the way Kannel works proves my > observation. When you get a DLR then you need to ACK this asap instead of > sending MTs first, because CMG (EMI) seems to be waiting for those > responses. I think they have implemented a way of making sure, a connected > application is not overloaded by traffic from CMG (generally, some kind of > window size implementation for the direction smsc->kannel). So if they > don't get ACKs soon enough, they just delay sending. Which eventually leads > to exactly the situation I described. Of course, you can say this does not > go along with the protocol, and I agree with that, but the problem remains > the same. For that reason I didn't call it a bug (as you might have > noticed). It's just that I think the lack of WindowSize parameter in the > receive direction made CMG implement a substitute, and that's what is > causing the problem. (At least, that's what I think.) > > Kind regards, > Holger. > > > Hi again, > > > > I do not agree here... We doesn't have any queue for ACK's. If emi driver > > receive DLR's then ACK's will be send immediately back, without any > > queuing > > (only tcp/ip buffering is here). That means, the right order is always > > there: > > 1) kannel -> send msg -> smsc > > 2) smsc -> send ack -> kannel > > 3) smsc -> send dlr -> kannel > > 3) kannel -> send next msg (depends on window size) -> smsc > > 4) kannel -> send ack -> smsc > > > > So I can not undestand, why it should happens here ? If it is happens, > > then > > (imo) CMG has a bug! emi is asynch. protocol and smsc may not wait for > > any > > > > ack's before sending ack's back! > > > > On Monday 04 August 2003 10:59, Andreas Fink wrote: > > > if this is really the case, then we have a bug to fix. > > > Bruno what you think of this? > > > > > > On Montag, August 4, 2003, at 10:55 Uhr, Holger Seiferth wrote: > > > > Hi, > > > > when using kannel with CMG SMSC and a provider which uses one > > > > connection to > > > > do both sending and receiving messages (incl. notification) there > > > > seems to be > > > > a kind of "Dead Lock" problem with sending messages and sending > > > > notifications. Situation is like this (I tried to simplify the > > > > description to make it > > > > easier to understand): > > > > I send 100 messages to Kannel. Kannel puts those 100 messages into > > > > its send > > > > queue. Then it sends out the first 5 messages (assuming WindowsSize > > > > is 5). > > > > Then I get back 5 ACKs and 5 notifications. After I got back the > > > > ACKs, Kannel > > > > sends out the next 5 messages. Then I get back 5 ACKs and 5 > > > > notifications, and > > > > so on. > > > > The problem is: > > > > Kannel seems to put the ACKs to the notifications in the same queue > > > > as the > > > > outgoing messages without any priority. So those ACKs are not sent > > > > until the > > > > last of the 100 MOs was sent. But we get into trouble, because the > > > > CMG SMSC > > > > keeps waiting for those ACKs and since they don't come, it's assuming > > > > that our > > > > side (meaning Kannel) is busy, so it delays sending the MT ACKs. > > > > Finally, we get into the situation when Kannel waits for MT ACKs > > > > (because > > > > CMG refuses sending them) and CMG waits for notification ACKs, since > > > > they are > > > > in the Kannel message queue. > > > > I think, to prevent this, Kannel would have to send any ACKs before > > > > sending > > > > any messages, meaning Kannel needs to set a higher priority on ACKs > > > > than on > > > > MTs. > > > > Is there any (configuration) solution for this problem? > > > > Thanks! > > > > > > > > Kind regards, > > > > Holger > > > > > > > > -- > > > > COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test > > > > -------------------------------------------------- > > > > 1. GMX TopMail - Platz 1 und Testsieger! > > > > 2. GMX ProMail - Platz 2 und Preis-Qualit�tssieger! > > > > 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. > > > > e-Post > > > > > > Andreas Fink > > > Global Networks Switzerland AG > > > > > > ------------------------------------------------------------------ > > > Tel: +41-61-6666333 Fax: +41-61-6666334 Mobile: +41-79-2457333 > > > Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland > > > Web: http://www.global-networks.ch/ [EMAIL PROTECTED] > > > ------------------------------------------------------------------ > > > > -- > > Best regards / Mit besten Gr��en aus D�sseldorf > > > > Dipl.-Ing. > > Alexander Malysh > > ___________________________________________ > > > > Centrium GmbH > > Vogelsanger Weg 80 > > 40470 D�sseldorf > > > > Fon: +49 (0211) 74 84 51 80 > > Fax: +49 (0211) 277 49 109 > > > > email: a.malysh at centrium.de > > web: www.centrium.de > > msn: olek2002 at hotmail.com > > icq: 98063111 > > ___________________________________________ > > > > Please avoid sending me Word or PowerPoint attachments. > > See http://www.fsf.org/philosophy/no-word-attachments.html -- Best regards / Mit besten Gr��en aus D�sseldorf Dipl.-Ing. Alexander Malysh ___________________________________________ Centrium GmbH Vogelsanger Weg 80 40470 D�sseldorf Fon: +49 (0211) 74 84 51 80 Fax: +49 (0211) 277 49 109 email: a.malysh at centrium.de web: www.centrium.de msn: olek2002 at hotmail.com icq: 98063111 ___________________________________________ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
