Number of SMPP sessions -- old vs. new method

Number of SMPP sessions -- old vs. new method SearchSearch
Author Message
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 94
Registered: 06-2004
Posted on Wednesday, December 15, 2010 - 02:47 am:   

Des, Bryce:

Noticed the follwing in v.20101104, which could be a bug:

If SMSC definitions are created the old way, by means of establishing each session manually, everything appears to be normal: connections are created with an OK after each session.

However, when we tried submitting messages to such binds, first the messages would time out and then all of the sessions of that bind.

We wouldn't have guessed if not for one 1-session bind in that server, which kept working while all others went down.

Deleting the extra definitions and specifying TransmitterCount=05 fixed it after service restart.

If the change was intentional it'd be better not to allow NowSMS interface connect more than once with the same credentials.

We had created the multiple-sesstion binds after applying the update (1st was a receiver and the next 5 TRX.) If the same problem occurs after updating a configuration with existing "old-style" multiple-session binds, it could cause a serious service disruption.

Kind regards,
Ashot

P.S. Noticed you adding long HEX srtrings to "SAR" - style message ID-s, which should prevent them from repeating in messages to the same number. I'd still change the format to that beginning with the hex numbers, to improve handling of these files by the OS.

Kind regards,
Ashot
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 2746
Registered: 08-2008
Posted on Wednesday, December 15, 2010 - 09:07 pm:   

Hi Ashot,

You're not running the 2010.12.14 that I posted yesterday, are you? It was supposed to promise improved handling of throttling errors in async mode, but it was rushed out of testing to address an unrelated problem for another user. The installer did not include an updated version of one of the DLLs.

There is a problem with this version that is very similar to what you describe, except that it affects all async SMPP connections with random timeouts.

For the change to how throttling errors are handled in async mode, one of the DLLs was not updated in the installer that I uploaded. A version mismatch with the DLL resulted in false timeout errors being reported.

I can't recreate any problems with 2010.11.04, even if I have multiple binds defined to the same server without using the TransmitterCount= setting.

But I'm having consistent problems with 2010.12.14. 2010.12.15 is being posted to resolve that problem (http://www.nowsms.com/download/nowsms20101215.zip)

However, if you are truly running 2010.11.04, I'm at a loss to explain why this would happen.

For now, I'd stick with 2010.11.04, which has seen the most testing, I just mention this because the problem seems so similar.

--
Des
NowSMS Support
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 95
Registered: 06-2004
Posted on Wednesday, December 15, 2010 - 09:50 pm:   

Hi Des,

Just double-checked: it's 2010.11.04. I wasn't even aware of a new version..

To recreate the scenario, you could try a configuration like that we've had this trouble with:

7 6-session outbound connections to different SMSC-s (all have an unpleasant tendency of not responding to submit_sm very quickly, hence many sessions and a large window,) all connections configured identically as follows:
- First session RX
- 2nd-6th sessions TRX with windowsize 25

2 one-session TRX connections to another NowSMS server, with window 5 - these were working fine at the time the other 7 were timing out.

All connections use verbose names via the Hosts file, instead of IP addresses. The top part of the SMSGW.INI file looks like:

[SMSGW]

QDir=c:\Now_File\Q\
MessageIDTrackingDir=c:\Now_File\SMPPData\
SMSInDir=c:\Now_File\SMS-IN\
UsersQDir=c:\Now_File\UsersQ\
LogDirectory=D:\Logs\
UsersDir=D:\UserLogs\
UseRouteCache=Yes
SMPPDataRetainDays=2
SeparateUserQueues=No
SMPPSeqRandom=Yes
OldRoutingLogic=Yes
TrackSMPPReceipts=Yes
ReceiptRequested=Yes
WebAuth=Yes
WebMenu=Yes
WebPort=xxxxx
SMPPPort=xxxxx

SMPPServerEnquireLink=120
SMPPServerMaxConnectionsPerUser=4
WebAuth=Yes
WebMenu=Yes

ReceiveSMSCharset=utf-8

[SMPP]
DefaultDelReceipt=Yes
SMSCRouteTLV=xxxx

[SMPPOptions]
forwardroute=1400,String,6

It's been 24 hours since changing the uplinks configuration to "new style" and no timeouts. We've changed the config by deleting session definitions 2 to 6 for all 7 connections, reconfiguring the 1st session in each from RX to TRX, adding windowsize=25 and TransmitterCount=05 and restarting the service. It fixed miraculously - while for the previous hour and a half three of us were scratching our heads real hard looking all over the place..

Note that SMSC definitions also had RoutePrefOnly=Yes and DefaultSMPPOptions=forwardroute=yyyyy - if that might be of relevance.

Hope you would figure it. Could indeed be a nasty surprise if this update goes wrong on a production system.

Kind regards,
Ashot