> Well my question was not about how it can be done but how they do do it > right now :]
we do terminate and restart smsbox to re-read the updated configuration. > What I meant here is that dynamic configuration loading inside Kannel > without stopping the smsc connections can be done (quite easily), thus > effectually same thing as never stopping bearerbox but restarting smsbox which is what we do. But you still have to stop and restart bearerbox if you change smsc groups (adding or modifying) and hence those who are not affected have to go down and up too. > Naturally. But show me the single SMSC connection that can do that. And > if you have several SMS center connections, you can have several > bearerboxes, too (yes, I know that if you need to reoute things between > them, this can still cause problems. That is just what I'm asking here, > does anyone really USE that or is it just speculation that it CAN be done > and used? Is it worth all the pain of message/ack/dlr transfer between > smsbox and bearerbox?) we had a maximum of 50 outbound msg/sec. as limit to an SMPP link. None was faster yet. And bearerbox smiles about those on our machine. I'm also thinking of problems arrising from the planed modularization. As far as I see we will have modularization (which is already there) for SMSC modules and SMS services (i.e. sendsms, sendota, sendringtone, sendlogo etc). which means if someone links in a SMS service module (into smsbox scope) and smsbox is implemented as threads inside bearerbox and the new code dumps core, the whole systems blows up. Which is not the way we would like to see it. > Usually the speed of applications (oh, the java servlets) and SMSC > connections is the only factor of the speed. The core Kannel can handle > like 1000-2000 msg/s of fixed answers in normal modern tabletop, > like 500-1000 HTTP based services (if the server is fast enough) > SMS centers usually do something between 10-50/s, java servlets less. Yeah, some sms-services on our side have a bottleneck of 20 msg/sec. on a servlet side, which is really depressing. At least PHP does 60 msg/sec. for the same application, so we are pushing for performance here. Stipe [EMAIL PROTECTED] ------------------------------------------------------------------- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de ------------------------------------------------------------------- wapme.net - wherever you are
