Hi Stipe, thanks for this patch. Quick review shows at least following:
+ resp->u.data_sm_resp.command_status = SMPP_ESME_RX_T_APPN; this should be ESME_RTHROTTLED. The same apply to deliver_sm. Please give some more time to review before commit. Regards, Alexander Malysh Am 3. Juni 2022, 17:08 +0200 schrieb Stipe Tolj <st...@kannel.org>: > Hi all, > > in certain conditions it may be feasible also to have MO throughput > control in terms of regulating how many messages we want to handle on > the MO side (including DLRs). > > For this purpose I have prepared the attached patchset, that introduces > the optional splitting of the config directives: > > group = smsc > throughput = X > > would means X as MT and MO throughput constraint, and > > group = smsc > throughput-mt = X > throughput-mo = Y > > where MT wise we have a X TPS constraint and MO wise a Y TPS. > > So far only the SMSC HTTP and SMSC SMPP modules have been implementing > in the patchset the MO throughput control. Other modules may follow if > required. > > Please review, comments as always welcome. If no objections, will commit > next week. > > (ONE argument that may be a decline reason is that the behavior WOULD > change with current setups, i.e. for SMPP connections this would imply > that we would also have MO throughput control for DLRs if the > 'throughput = x' value is configured. A way to solve this is to keep > 'throughput' for MT wise only, and introduce 'throughput-mo' as the new > one for MO control. Comments?) > > Thanks, > Stipe > > -- > Best Regards, > Stipe > > ------------------------------------------------------------------- > Koelner Landstrasse 419 > 40589 Düsseldorf, NRW, Germany > > tolj.org system architecture Kannel Software Foundation (KSF) > http://www.tolj.org/ http://www.kannel.org/ > > mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org > -------------------------------------------------------------------
