Hi, after changing window size I don't get into that situation anymore. I also tried window size 1 and works even faster, so I think I'm going to stick to window size 1 as long as there is no indication of a problem with this. If you should find any explanation for this, I'd be interested. I'll keep a close look on this as well and keep you informed. Thanks for your help!
Kind regards, Holger. > 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 > -- 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
