On Thu, 2004-10-07 at 23:36, Alan McNatty wrote: > Hi Kalle, > > It would be good to understand more the impact on doing this (as you > note). Please consider the following scenario ... > > Often connections to SMSC are bandwidth limited (we have some SMPP links > over limited FR for example). What this can mean is (under load) that > there is not as much traffic inbound as out. > Please note that this patch does NOT wait that message is handled by SMSC driver (which would take time if there are queues), but instead gets an immediate response as soon as bearerbox replies. Thus the delay is milliseconds when compared to old one.
The idea of waiting for SMSC ack/nack is in my plan. However, as this could be delayed even seconds, THAT feature would only be used if so configured/requested as it cannot be used with heavy traffic. (that feature would be based on current DLR implementation and there would be a list of possible problematic scenarios) > Also if load balancing with internal queues - in the event one SMSC link > is dropped the message queues are effectively shuffled. What would > happen if we're waiting to hear back from SMSC about message and the > link is dropped, etc? We would need to cope with these scenarios. > See above. This current reply is based on what bearerbox _immediately_ replies when it receives SMS from smsbox (and which was previously just discarded by smsbox). So, in exchange for some milliseconds, the caller gets information if there is some basic problems.. (no SMSCes connected, bad configuration,...) If you check out the original code (bb_boxc.c, line 253 and smsbox.c, line 191-196) these messages are already flying around (in fact, have been there for over 4 years...). They were just not used... (blame me =) -- &Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
