Paul Keogh kirjoittaa tiistaina, 4. kesäkuuta 2002, kello 14:51: > Yes, but when this is triggered bb_smscconn_receive () logs the event > and > returns -1. All the SMSC drivers except HTTP ignore the return code from > bb_smscconn_receive (). Therefore, the message is silently dropped from > the application and the SMSC point of view. This is IMHO a bad thing and > not something you could use in a production environment. I think a > better solution would be to; > > * When possible, map the queue full event to an SMSC protocol error > indicating a temporary resource shortage; otherwise fail the message > with the most appropriate error code. > > * Introduce a flow control admin. message to tell the SMS box (and any > other > clients using the SMS box interface) to stop/start sending messages. > The SMS > box could in turn signal to the various sendsms applications that a > temporary > resource shortage event has occurred (HTTP 503 maybe ?) > > * Use high and low watermark variables instead of maximum-queue-length. > This prevents > thrashing around the maximum-queue-length value. A sort of SMS > hysteresis curve :-).
Maximum-queue-length is supposed to prevent crashing caused by too long queues. Congestion control is used to *prevent* long queues. It is, of course, something Kannel can use. Aarno
