SMPP delivery receipts, asynchronous mode

SMPP delivery receipts, asynchronous mode SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through February 02, 2006 » SMPP delivery receipts, asynchronous mode « Previous || Next »
Author Message
ashot shahbazian
New member
Username: Animatele

Post Number: 38
Registered: 06-2004
Posted on Tuesday, August 16, 2005 - 04:51 am:   

Hi Bryce!

We've tested the delivery receipts forwarding with NOWSMS and discovered some shortcomings:

-if the service is restarted all receipts for previously sent messages are lost

-if the message ID format in the receipt differs from that originally assigned, e.g., if it was assigned in hex but came with the receipt in decimal, NOWSMS would not route it to the user bind. The receipt stays in sms-in directory even though the values of both match. The same happens if the id in the receipt had zeros added in front of it (many SMSC-s would do it for some reason.)

There is no mention of NOWSMS supporting asynchronous mode for upstream connections. This would limit the speed of submitting messages to SMSC if it is slow to respond, is far away or on a slow IP link.

Are there any workarounds in the current release or this may be added in the future?

Thanks!
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4755
Registered: 10-2002
Posted on Tuesday, August 16, 2005 - 10:34 am:   

Hi Ashot,

We will support asynchronous mode in the next major release, with a configuration setting that allows you to specify the maximum number of oustanding SMPP operations allowed.

Unfortunately, I don't have a hidden setting that enables this at present. But we are currently testing a special version at one customer site where this was required. And I'm hopeful that we'll be able to release it in early October.

At present, if your upstream provider will allow multiple simultaneous SMPP connections on the same account, then this can be an alternative.

Regarding the other questions ...

Restarting the service should not have any impact on receipts. Can you explain what you have seen?

I'd also like to see some examples of the differences in message id format that you have observed.

There was another thread out here where it was observed that the SMSC was returning the message id only in the text of the message, and not in the receipted_message_id field. And I believe we will be able to make some changes to parse it from the text of the message.

But, I am a bit confused about how we would recognise variations in the message id between what was returned as "message_id" in "submit_sm_resp" and "receipted_message_id" in "deliver_sm".

When we receive the delivery receipt, we need to be able to match the "receipted_message_id" (or in the future, a similar value parsed from the text) with the originally assigned "message_id".

What transformations would you suggest in order to be more flexible on finding this match if the match is not exact?

-bn
ashot shahbazian
New member
Username: Animatele

Post Number: 39
Registered: 06-2004
Posted on Tuesday, August 16, 2005 - 08:07 pm:   

At present, if your upstream provider will allow multiple simultaneous SMPP connections on the same account, then this can be an alternative.

This would not work, as even if the operator allows it their ESME would not distinguish between the multiple binds and would send the receipts over wrong ones in random, thus confusing receipt routing by NowSMS. We've actually tried it, and for 10 parallel binds only about 10% of the receips successfully routed to our user account and roughly 90% stayed in sms-in directory.

As for using parallel uplinks, each with its own login it is highly problematic for several reasons:
- operators just don't like it as I suppose it makes their billing more complicated
- some SMSC-s would only allow specific Sender ID ranges for a single user, which neans that if our first bind allows Sender ID-s in a numeric range 000000 to 999999 then the messages with Sender ID-s falling into this range and coming to 2nd and other binds would return "Invalid Source ID" errors.

Restarting the service should not have any impact on receipts. Can you explain what you have seen?

It does, unfortunately. We've tested it by sending a message to a switched-off handset then stopping the gateway service and starting it over. Then we turned on the handset and received the message. The DR came from the SMSC but it never routed to the user bind where the submission came from, it was stuck in the SMS-IN directory.

how we would recognise variations in the message id between what was returned as "message_id" in "submit_sm_resp" and "receipted_message_id" in "deliver_sm".

Two of the known variations are hex/decimal and hex/hex with leading zeros. This is characteristic of Comverse SMSC-s, which are very common. Examples:

Leading zeros:

2005-07-30 17:34:39,42EB8899.req,192.168.0.20,+447708313150,OK -- SMPP - 212.120.000.000:0000,SubmitUser=0test;Sender=07624000000;SMSCMsgId=2d08e90d;Text ="test dr O2 4"

2005-07-30 17:34:46,+447708313150,Text,id:002d08e90d sub:001 dlvrd:001 submit date:0507301934 done date:0507301934 stat:DELIVRD err:000 text:test dr O2 4,07624000000

Hex to decimal:

2005-07-22 10:18:38,42EB8012.req,192.168.0.20,+447708313150,OK -- SMPP - 212.120.000.000:0000,SubmitUser=0test;Sender=07624000000;SMSCMsgId=0a429c56;Text ="hi"

2005-07-22 10:18:46,+447708313150,Text,id:0172137558 sub:001 dlvrd:001 submit date:0507221217 done date:0507221217 stat:DELIVRD err:000 text:hi,07624000000

The value in the receipt matches that in the original submission.

What transformations would you suggest in order to be more flexible on finding this match if the match is not exact?

Just matching numeric values, unless there could be other variations which we're not aware of.

In our tests, the message ID-s are seemingly where they belong to. I would be cautious in parsing ID-s from the text of the message, as the message ID-s returned by some SMSC-s are as short as 3 or 4 digits. There may be erros due to numeric content in the text body confused for the message ID. If you find out which particular SMSC would put the ID into the text body and get samples you could then enable the setting, but announce that it's for this particular XYZ SMSC. T}his way, you would look for the ID only where it's expected to be in the text, to avoid errors.

Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4814
Registered: 10-2002
Posted on Wednesday, August 31, 2005 - 04:25 pm:   

Hi Ashot,

Sorry to take so long to respond, but we have been working on these and related issues.

On the first issue, routing of delivery receipts when you have multiple binds to the same SMSC ... that is a bug on our part.

We should have been handling that correctly, but we are not. I'm expecting to post an update within the next 24 hours which will address this issue.

It is important that you define the multiple connections to the same SMSC in NowSMS with the exact same server host name and port number. When you do this, NowSMS will display the entries in the SMSC list like this: "SMPP - a.b.c.d#2:xxxx", "SMPP - a.b.c.d#3:xxxx"

When processing the delivery receipts, we will recognise that all of these connections are to the same SMSC, and process the receipts accordingly. (Currently, we only handle the receipt correctly if it arrives via the same SMSC connection that it was sent out on. But this fix will group multiple connections to the same SMSC so that receipts can be handled accordingly.)

Regarding the service restart causing delivery receipts to not be routed correctly, this still has me puzzled. If this problem persists after the update, we might have to look more closely at debug logs.

Regarding the variations in receipted message id formats, we'll go ahead and remove the leading 0's from any comparison. We'll also try decimal-to-hex and hex-to-decimal conversions in an attempt to find a match. So that should handle the variations that you describe above.

Regarding parsing the receipt message id out of the text of the message ... I share your concerns. We're only going to parse this text if the message type indicates that it is a receipt, and there is no receipted_message_id associated with the receipt. And even then, we are going to accept the value from the text as a message id if it matches an id from a message that we sent.

So I think we'll be safe with that approach.

I'll post a follow-up as soon as the update gets made available for download.

-bn

Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4817
Registered: 10-2002
Posted on Wednesday, August 31, 2005 - 09:08 pm:   

Follow-up. The update that I referenced above has been posted.

Download link for update (v5.51e): http://www.nowsms.com/download/latestpatch.zip

Related threads:

http://support.nowsms.com/discus/messages/1/10644.html
http://support.nowsms.com/discus/messages/1/10806.html
http://support.nowsms.com/discus/messages/1/10825.html
ashot shahbazian
New member
Username: Animatele

Post Number: 40
Registered: 06-2004
Posted on Thursday, September 01, 2005 - 05:25 am:   

Hi Bryce!

Regarding multiple upstream connections with the same system ID/password:

I never expected you to fix it, was rather contemplating about async mode. I'm not aware of any other SMPP server implementation that would handle it as you've described. Great job!

As for the lost DR-s, I think I was testing it with 5.51b. I'll download the current update and let you know if it's handling it differently.

Message ID conversion: what would happen if the originally assigned ID had a zero in the baginning, and the ID in the DR had 2 zeros added, i.e., it would have 3 zeros? (stupid question, really - I just saw Msg ID-s beginning with zero.)

Are all new features (support for simultaneous binds, processing and matching Msg ID-s in DR-s and parsing the Msg ID from the text of the DR) already working in v.5.51e?

Thanks!!
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4825
Registered: 10-2002
Posted on Thursday, September 01, 2005 - 03:10 pm:   

Hi Ashot,

We'll definitely get support for SMPP async mode into general release before the end of the year, because providers won't always allow multiple binds.

But multiple binds can serve as a workable alternative in some situations.


quote:

Message ID conversion: what would happen if the originally assigned ID had a zero in the baginning, and the ID in the DR had 2 zeros added, i.e., it would have 3 zeros? (stupid question, really - I just saw Msg ID-s beginning with zero.)




That would be ok. We're basically ignoring all leading 0's in the id's from the submit_sm_resp, and the DR.


quote:

Are all new features (support for simultaneous binds, processing and matching Msg ID-s in DR-s and parsing the Msg ID from the text of the DR) already working in v.5.51e?




Yes. The only issue discussed that we're not addressing at this time is SMPP async mode.

-bn



ashot shahbazian
New member
Username: Animatele

Post Number: 44
Registered: 06-2004
Posted on Saturday, September 10, 2005 - 04:23 am:   

Hi Bryce!

Thanks for the updates! We've tested the DR forwarding and it seems to be working wonderfully.

There appears to be a serious performance problem however if we try to build a relatively simple message routing mechanism using NowSMS.

The aim is to enable users sending via different SMSC-s according to the network coverage of each particular SMSC. The second objective is to be able to maintain the stats of messages sent via each of the SMSC-s for each destination network.

We've built a setup consisting of 2 NowSMS servers connected to each other within LAN, the second one hooked up to an SMSC emulator (remote location, ping about 60 ms) via 10 concurrent SMPP binds, each representing an upstream SMSC connection.

The first server is connected to the second one via SMPP "crossbinds" each representing a "route", i.e., a path which enables sending messages only to one particular destination network via a particular SMSC. The stats per destination net thus can be viewed on the user account on the second server set up for that crossbind, and the routing to the crossbind is done on the first server by means of allowing sends to relevant network prefixes only, via RoutePrefOnly=Yes and RouteX=+CCNP* option. On the second server, crossbinds corresponding to destination nets supported by the SMSC uplink bind are allowed on that uplink by means of AllowedUserOnly=Yes and AllowedUserX=crossbind_name.

The setup would apear to be a bulky one but manageable for networks in half a dozen countries and 2-3 SMSC-s. We couldn't think of a more portable solution. The machines used were PIV-3000 with 512M RAM, WinXP PRO SP2, dual SATA disks with a SATA RAID controller. The OS on the machines were fresh install, set up for multi-threading, optimised for best performance and stripped of any irrelevant services, which were disabled. HDD-s were defragmented, no other software but performance monitor running and no 3d party software installed.

We've tested the system performance with a single crossbind. The throughput between the 2 servers was about 30 SMS/sec. With 40 crossbinds, if the queue consisted of randomly mixed messages to destination numbers falling into the range supported by the crossbinds the throughput decreased to 3-4 SMS/sec. With 80 crossbinds, it went down to less than 2 SMS/sec. The bottleneck was the crossbinds between the 2 NowSMS servers; the second one, connected upstream to the emulator did not have any messages accumulating and its CPU load remained close to 0. None of the crossbinds would send faster than 1 SMS/sec, often having pauses over 5 sec. between sends, with the queue on the first server having plenty of messages for that link.

Injecting 200-300 messages into the 1st server's queue would bring its CPU utilisation close to 95-98% and would halve the sending speed as compared to that when the messages were injected at about the same speed as pushed to the 2nd server. This non-linear behaviour brings about a concern that in real-world environment such system would be brough to a halt by a relatively small batch of incoming messages. Once it hits the 1st server, the performance degrades and the system would no longer be able be process the same number of "streaming" messages as before, accumulating more and more messages in its queue and stalling altogether.

We've first tried it with SMPP links to the second server with sys id-s defined by NowSMS as 192.168.1.5:9999#2, #3 etc., then changed it using different names for every route, defined in HOSTS file. That made no difference. We've also reconfigured it with links between the servers over HTTP. Peformance has increased only marginally.

Our software engineers tried analysing the performance counters; their conclusion was that the program is probably using some simple search mechanism for determining which route (crossbind) was suitable for a particular message, perhaps the mechanism built into the OS. Using a binary tree for these searches should greatly increase the throughput, in their opinion.

Another observation was that it seemingly reads the .req file in a queue line-by-line, instead of caching it into memory and manipulating it without accessing the disk that often.

Within a few hours of tests, they have also noticed that smsin, smsout and smsweb logs would become very fragmented, several thousand fragments per log file, which, as they think is the reason the system performance increases by 20-25% after defragmenting the disks, even though it was perviously defragmented a few hours ago.

Would you have any ideas about remedying it? Please email me if you'd like to run tests on that system, I'd give you remote access to it.

BR,
Ashot

P.S. I wrote to Keith Norris some time ago specifying what we'd like to see in terms of message routing provisions for SMPP. We haven't had the knowledge of any performance limitations then, and it was more complicated than what's described here, a "wish list" of sorts. To have a clearer idea what our ultimate objective is please find below the part of that communication:

1. Dynamic configuration for "Preferred SMSC Connections" where we could add routes (country codes and operator prefixes) for an uplink definition in the smsgw.ini file without the need to restart the service

2. Ability to define daily message quotas per terminating network per SMSC uplink, somewhat similar to that implemented for user accounts

3. Auto routing mechanism, which would allow:
- rerouting traffic destined for an uplink to another uplink supporting the same destination if
- the first SMSC is down (no bind)
- the daily quota for fhe first SMSC has been reached

2 and 3 would probably require a narrower definition of destinations, i.e., instead of a list of country codes and prefixes the configuration file should contain operator definitions (prefixes can be added by the user.) For example, while allowed routes for an uplink definition would look like:

Route1=AT_A1
Route2=DE_D2
etc
the operator prefixes are defined globally in the [SMSGW] section of the ini file, for example
Operator1=AT_A1;+43664
Operator2=DE_D2;+49162,+49172,+49173,+49174,+49152

The above would generally be a helpful addition, as the list of mobile prefixes for the UK is about 300 long, and that for the U.S. and Canada is many thousands. Having that specified for each of the uplinks in a large system would make the ini file very large and barely comprehendable.

ashot shahbazian
New member
Username: Animatele

Post Number: 45
Registered: 06-2004
Posted on Wednesday, September 14, 2005 - 05:32 am:   

Hi Bryce!

Did you have a chance to look into the problem? We're about to take that system apart, would you prefer running tests on it or you would recreate the scenario yourself?

BR,
Ashot
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4896
Registered: 10-2002
Posted on Thursday, September 15, 2005 - 05:54 pm:   

Hi Ashot,

Actually, we've been looking at this issue over the past few days.

Well, there are a number of issues here, but performance is the issue that gives us the most pause.

Indeed, the more SMSC connections (with restrictive routes) that are defined, the slower things get.

We've run a number of different tests, and quite a few different experiments ... including some rather elaborate techniques that succeeded in only slowing things down ...

But in the end, we did come up with some optimisations that seem to make a rather significant difference.

And, in particular, when we enable asynchronous mode for an SMPP connection, in conjuction with these optimisations, we can avoid most of the performance degredation that occurs when having a large number of SMSC connections active.

In my test scenario, I'd inject around 5000 messages. With 80 SMSC connections defined, I could only get a throughput of 3-4 messages per second.

With the optimisations, and async SMPP (for the sake of my test, I used a window size of 100, and didn't experiment with other sizes), I managed to get 85-90 messages per second with all of the messages routed to SMSC connections over the internet (as opposed to local servers).

The important factor here is that whether there was 1 SMSC defined, or 80 SMSCs defined, the overall throughput was not significantly different.

Connecting to a local SMSC vs. connecting to a remote SMSC also didn't make that much difference, as long as the remote SMSC could keep up with the pace.

Obviously, we still need to run more tests ...

1.) To make sure that we didn't introduce any new bugs in the process.

2.) To test different window sizes.

3.) To simulate more real-world scenarios.

But I think it's a step in the right direction.

Because there are some internal structural changes that could introduce new problems, I'm going to upload this update to a different URL: http://www.nowsms.com/download/nowsmsasync.zip.

Note that to enable async mode for a connection, you need to edit SMSGW.INI, and under the [SMPP - host:port] header, add WindowSize=### to specify the window size to be used.

-bn
Anonymous
 
Posted on Friday, September 16, 2005 - 07:48 am:   

Dear All,
I'm trying to use this delivery receipt feature but I stuck. If I specify TrackSMPPReceipts=Yes then NowSMS enter an endless loop (trying to match the receipt?) and the message stay there in the \Q directory. It happened with both the SMSC simulator (OpenLogica) and the real one.I'm using the latest (5.51h) version of NowSMS. Can anyone help me get out of this?
Thanks and BR
Levi
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4927
Registered: 10-2002
Posted on Friday, September 16, 2005 - 07:57 pm:   

Hi Levi,

There's no way that NowSMS could get into a loop trying to match a delivery receipt. If we don't have a record of the message id, it just gets routed without a message id.

Are you sure that your problem has anything to do with delivery receipts? i.e., if you don't have TrackSMPPReceipts=Yes in the SMSGW.INI file, does the same problem occur?

I just can't see any way that this setting could cause this type of problem.

So I suspect there is some other problem.

I think I would need to see a debug log to understand the message flow. It sounds like there might be some sort of circular routing defined. Or if the message is staying in the Q directory, then perhaps the SMSC connection is failing?

In any event, a debug log would help me understand, because I just don't have enough details to troubleshoot based upon your brief posting above.

To enable the debug log, use the checkboxes on the "Serial #" page of the configuration dialog. Then, I'm interested in seeing the SMSDEBUG.LOG and SMPPDEBUG.LOG files so that I can see what messages are getting routed and how they are being routed.

-bn
ashot shahbazian
New member
Username: Animatele

Post Number: 46
Registered: 06-2004
Posted on Friday, September 16, 2005 - 09:09 pm:   

Well I've encountered the same weird problem yesterday. Sent one message, got about 60.

I was testing whether v.5.51f would truncate the 0-s from the msg ID-s in DR-s generated by a Comverse SMSC (it did not.) I connected from my notebook to a test machine, which was connected upstream to a live gateway.

NowSMS v.5.51b was set up on the notebook and v.5.51f on the test server.

On the notebook setup I tried submitting a message without first checking "require web authorisation", although I set a sender ID in the only user definition I have there. The only SMSC definition in the notebook was the connection to the test server. I submitted a message once, through the Web interface. It did not deliver and the req file stayed in the queue while I was thinking what to do next. It was not trying to deliver, there were no entries in the log files and the rety counter in the file itself did not change.

Then I clicked "require web authorisation," set a password on the user account, closed the web interface, opened it once again (it asked for a username/password) and submitted another message. Messages started delivering approximately once every 5 seconds. The first message (which in the logs of the notebook did not have the submituser=xxx field) delivered 50 or 60 times, each attempt was recorded in the test machine's logs. In the smsout log of my notebook computer there was only one entry for that message, and one for the second one (which delivered only once.) In the smsin, smsout and smsyyymmdd on the test machine there were 50-60 attempts, all successfully delivered on my handset and DR-s received too. The smsout log clearly showed that the messages came from a server with my notebook's IP address. I couldn't believe my eyes. I checked the \q directory on the test server but I didn't catch any queue files.

What I did next was I deleted a few thousand .sms files from the \sms-in directory (those were receipts left from previous tests) then I checked back the logs and noticed that the loop stopped by itself. Interestingly, the second message I submitted from the notebook delivered only in the end, after the last looped message, even though the process continued for a few minutes.

Something similar happened (don't remember the details) a few months ago while we were setting up the system to test the multiple queue functionality. The messages would keep delivering every few seconds, with no visible entries in the queue. Stopping the service would stop deliveries, starting would resume. It only stopped after I've rebooted the server.

Sounds like a detective story, doesn't it?

I can try recreating the scenario if you like, turning on the debug files first...





Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 4934
Registered: 10-2002
Posted on Friday, September 16, 2005 - 09:22 pm:   

Hi Ashot,

That does sound like a mystery.

On the leading 0's, I'm pretty confident that we're handling those receipts correctly now. Try it again with 5.51g or 5.51h.

I finally got an explanation from a provider as to why the delivery receipts are in decimal and with leading 0's. It's all based on a very literal reading of the vague text "example" in the SMPP v3.4 specification. This would explain why the "id:" in the text is decimal with leading 0's ... but not the actual receipted_message_id field being in this format.

Anyway, I don't have any clues about the repeated message. I thought maybe there might be an issue with using the "SeparateUserQueues=Yes" setting without authentication enabled. But I can see that in that case the submitted message just goes into the main Q directory like I expected.

So I hope you can recreate it, or come up with some explanation.

-bn
ashot shahbazian
New member
Username: Animatele

Post Number: 47
Registered: 06-2004
Posted on Saturday, September 17, 2005 - 02:06 am:   

Hi Bryce!

Our engineers have tested the g and h patches; according to their report, the leading zeroes truncate now and the DR-s get properly passed downstream through the servers.

However, they have not noticed any significant improvement in throughput in a scenario with 40 concurrent binds between 2 NowSMS servers, neither with g nor with the h release, except that the CPU load went down by 20-25%. They've tried windowsize 5,10,50,100 and 500. I will get my hands on that setup over the weekend and try to play with it too.

You are right about that example in the SMPP specs. First thing we did was to re-read the spec, and then to try to bind to that SMSC with SMPP 3.3 thinking that it would work differently. It didn't bind obviously.

The submitted message may have been appearing in the server's \q directory, it's just I may have not seen it since it may have stayed there for a very short time before being submitted.

The separateuserqueue setting couldn't have been the reason as it wasn't enabled in my yesterday's test.

I'm having vague thoughts that the loop may have been the result of some inconsistency in handling the sm-resp for the message with no user ID, and that may have conflicted with the DR routing functionality. Tracksmppreceipts was set to yes both on the server and on my notebook.

The f patch, as I was told, already has the async functionality, and they have noticed the service freezing and locking up the CPU at 100%, which would normalise if a "test" button is pressed (which disconnects and connects the bind I suppose.) They've observed it with the f patch, but not with g or h.

I'll surely try to recreate the "loop" situation and would post the logs.

BR,
Ashot
Anonymous
 
Posted on Saturday, September 17, 2005 - 06:32 am:   

Hi Bryce,
If I have TrackSMPPReceipts=No then everything is just fine (excepts of course that the @@RECEIPTMESSAGEID@@ parameter is empty). FYI, I don't specify any routing info at all so I suspect that you second suspect might be true: that is the SMSC connection is falling. In fact, after trying to send an SMS with the option on, the SMSC simulator says I got a couples of connection instead of only 2 (in-out)!
The debug files are not useful because those were re-created after each try: I attached the SMPPDEBUG.LOG and SMSDEBUG.LOG and SMPPDEBUG.BAK here but I'm afraid that it won't help you. Really weird!
application/octet-streamSMSGW.INI
smsgw.INI (0.7 k)
application/octet-streamSMPPDEBUG.BAK
SMPPDEBUG.BAK (2.5 k)
application/octet-streamSMPPDEBUG.LOG
SMSDEBUG.LOG (0.1 k)
application/octet-streamSMSDEBUG.BAK
SMSDEBUG.BAK (0.1 k)
application/octet-streamSMSDEBUG.LOG
SMSDEBUG.LOG (0.1 k)
ashot shahbazian
New member
Username: Animatele

Post Number: 48
Registered: 06-2004
Posted on Wednesday, September 28, 2005 - 10:27 am:   

Hi Bryce!

On the throughput improvement issue: there is a bug in the SMSC emulator we've used that caused messages from the second server being rejected due to queue overflow. We've taken measures to prevent this, and the picture's become much brighter. I apologise for the misinformation in the previous post.

The setup is servers with concurrent binds between them and binds to an SMSC emulator (running on the same machine) on the 2nd server. Synchronous and Async modes were tested, with DR-s on and off. Here's the translation of the engineer's report:

Quote:

In all cases where Async mode is used the WindowSize=50 setting was specified.

sending 1000 smsс DR-s requested. Both servers in Sync mode:

Server1. sending 41 sms/sec, DR-s receive speed 38 sms/sec
Server2. sending 41 sms/sec, DR-s receive speed 38 sms/sec

sending 1000 smsс DR-s requested. Server1 in Sync mode, Server2 in Async mode:

Server1. sending 53 sms/sec, DR-s receive speed 48 sms/sec
Server2. sending 55 sms/sec, DR-s receive speed 45 sms/sec

sending 1000 smsс DR-s requested. Both servers in Async mode:
режиме

Server1. sending 53 sms/sec, DR-s receive speed 53 sms/sec
Server2. sending 59 sms/sec, DR-s receive speed 50 sms/sec

sending 1000 smsс DR-s requested. Server1 in Sync mode, Server2 in Async mode:

Server1. sending 45 sms/sec, DR-s receive speed 44 sms/sec
Server2. sending 59 sms/sec, DR-s receive speed 50 sms/sec

sending 7000 smsс DR-s requested. Both servers in Async mode:

Server1. sending 51 sms/sec, DR-s receive speed 46 sms/sec
Server2. sending 50 sms/sec, DR-s receive speed 49 sms/sec

sending 1000 sms with no DR requested. Both servers in Async mode:

Server1. sending 111 sms/sec
Server2. sending 125 sms/sec

I also checked with a larger queue, in order to compensate for the time it takes to create it.

sending 5000 sms with no DR requested. Both servers in Async mode:

Server1. sending 169 sms/sec
Server2. sending 167 sms/sec

sending 5000 sms with no DR requested. Server1 in Sync mode, Server2 in Async mode:

Server1. sending 168 sms/sec
Server2. sending 167 sms/sec

sending 5000 smswith no DR requested. Server1 in Async mode, Server2 in Sync mode:

Server1. sending 172 sms/sec
Server2. sending 172 sms/sec

sending 5000 sms with no DR requested. Both servers in Sync mode.

Server1. sending 196 sms/sec
Server2. sending 194 sms/sec

It appears that in Sync mode with no DR-s the speed increases. I've double-checked it. There's a slight variation (e.g. 168-178 and
196-206,) but the proportion's the same - in Sync mode it is notably faster.

Unquote.


I've watched it while some of these tests were running. There was never a CPU lockout, it would run at not more than 50-70% on either machine even with a 10,000 queue.

It seems the DR request/receiving/processing slows the process down, performance without the DR-s is at least 3 times that of with the DR-s. TRX binds were used in our tests; we would try to re-create the same scenario with separate transmit/reveive binds to see if it improves with the the DR-s requested.

We would also try testing on two Dell servers, 1850 dual Xeon 3.0 with 256MB RAID controllers; these machines are many times faster than what we've used; this way we can make conclusions as to what depends of the hardware performance and what does not.

Here are the smsgw.ini files we've used (the last configuration tested) and the text file used to generate the queue:








application/octet-stream
machine 1 - smsgw.ini (11.7 k)
application/octet-stream
machine 2 - smsgw.ini (5.7 k)
text/plain
dlist.txt (17.5 k)


I had no luck re-creating the situation with the messages looping; would try it once again next week.

I'll update on the tests with separate tx/rx binds and those on the fast servers.

BR,
Ashot
Anonymous
 
Posted on Saturday, October 01, 2005 - 04:16 am:   

Hi there,
I've tested on 3 different machines and the result is the same: if I set TrackSMPPReceipts=Yes then the NowSMS stuck in an infinite loop making a lots of connection to the SMPP server trying to send out the messages from the outbox (\Q folder). I attached here the OpenLogica SMSC simulator. It needs the JRE to run. Just execute the BAT file and it will run. Specify the username/password in NowSMS as pavel/pavel and you will have the connection. I really appreciate if you (specially Mr. Norwood) can take a look at it and at least tell me if the phenomenon is occuring on your computer or not.
Many thanks and BR
Levi
application/x-zip-compressed
OpenSMPP SMSC simulator.zip (178.6 k)
Anonymous
 
Posted on Saturday, October 01, 2005 - 04:19 am:   

I forgot to tell you that the phenomenon is not occuring with the 5.51 version (maybe because the option was not available back there?) but it did happened with 5.51c and 5.51h.
BR Levi
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5051
Registered: 10-2002
Posted on Wednesday, October 05, 2005 - 04:52 pm:   

Hi Levi,

If you send a message with return receipt requested, the simulator tries to generate a receipt back.

However, there are a few problems with the receipt.

First, the esm_class flag is not set to indicate that it is a receipt. Because of this, the TrackSMPPReceipt=Yes setting doesn't even attempt to process the message. (So I would expect the same result with this setting omitted.)

Second, the recipient address in the receipt message is the same as the recipient address in the original message. So, if you have an "SMS Users" account defined with a routing for this address, it is going to get routed to that "SMS Users" account. That is likely what is triggering an infinite loop in your setup.

The problem is not "TrackSMPPReceipts=Yes", but rather the problem is that the receipts being generated by the simulator are not properly recognised as receipts.

When you send a message with a delivery receipt requested, the simulator responds back with an invalid format delivery receipt. And somehow, because of your configuration, this triggers an infinite loop.

I can't imagine what type of configuration would trigger such an infinite loop. But hopefully that provides some more explanation.

All that said, I suppose we could add some more smarts to our implementation, and support the bad receipt format generated by the simulator.

In fact, I seem to remember investigating another issue where the SMS provider confused the sender and recipient in the receipt. I suspect there are probably some more souls that have tried to use the source for this simulator as a basis for their implementation.

So, we'll extend TrackSMPPReceipt=Yes a bit further to be able to support the receipt format for the simulator. This will appear in v5.51j or later, which will probably be available by late this week.

Please note, however, that I do not expect an update to fix your infinite looping problem. I believe that the infinite looping problem that you are experiencing is a configuration issue.

When you submit a message to the simulator with a receipt requested, it replies back with a delivery receipt message. The delivery receipt message that comes back is a message addressed to the original recipient of the message. If you route that back to the simulator and set the receipt requested flag again, then you'll end up with a loop.

-bn

Anonymous
 
Posted on Thursday, October 06, 2005 - 08:05 am:   

Hi Bryce,
Many thanks for your exhaustive reply.The prob seem weird to myself too.Following your advice I restarted the NowSMS service with a clean SMSGW.INI (attached) where I cleared everything like SMSUsers and even the 2-Way commands. Then I tried to send a text SMS from the NowSMS Web interface and ... I still got the infinite loop !It is really driving me nuts cause I know that it IS working for other guys!I'm using the 5.51i version.
Can you send me just a simple version of WORKING smsgw.INI file so I can try it?
Really appreciate your help!
Levi
application/octet-stream
smsgw.INI (0.3 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5082
Registered: 10-2002
Posted on Thursday, October 06, 2005 - 07:45 pm:   

Hi Levi,

Can you post an SMSDEBUG.LOG and SMPPDEBUG.LOG showing these looping messages? I would like to understand where the messages are coming from.

I don't understand why things would be looping. In this case the delivery reports should simply be coming in as messages and deposited in the SMS-IN directory.

-bn
Anonymous
 
Posted on Friday, October 07, 2005 - 01:42 am:   

Hi Bryce,
Here I attached the debug files (and the BAK files) but as I mentioned, it may helps you a little caused it seems NowSMS reset the debug files as it's trying to reconnect to the SMPP server. I also attached the 2nd version of those debug files when the TrackSMPPReceipts=No was set. In this case, the delivery reports came in alright to the SMS-IN (also attached). Trying to figure it out, my guess is when NowSMS is trying to send the SMS out it waits for a response from the SMPP. The SMPP comes back but during the match of the receipt, some error happens and the connection was dropped. NowSMS reconnects to the SMPP server and as it still finds the out-request in the outbox, it is trying to send it again - it here we got the situation.
My question is have you tried to connect to the OpenLogica simulator SMPP in your environment? Everything was going alright there with it?
BR Levi
application/octet-stream
SMSDEBUG.BAK (0.2 k)
application/octet-stream
SMPPDEBUG.BAK (2.2 k)
application/octet-stream
SMSDEBUG.BAK (0.2 k)
application/octet-stream
SMPPDEBUG.LOG (4.9 k)
application/x-zip-compressed
debug-OK.zip (2.2 k)
application/x-zip-compressed
SMS-IN.zip (0.8 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5094
Registered: 10-2002
Posted on Friday, October 07, 2005 - 07:37 pm:   

Hi Levi,

The only weird thing about your setup, is that I don't understand why you are using asychronous SMPP to connect to a simulator. I'd remove the "WindowSize=" parameter from your SMSGW.INI file, and see if that has any bearing on this.

But yes, I've used the simulator. And I don't see anything unusual about it.

I also can't make sense of your logs, as there is no information in them.

I'm guessing that the NowSMS server is resetting every time it submits a message, because something is going wrong.

That would explain the short debug logs, and the loop.

But I don't know why this would happen. I don't think it has anything to do with the receipt coming back from the server ... because presently we are not recognising those receipts as true receipts, so they bypass all TrackSMPPReceipts processing.

What version of Windows are you running on?

I'm also wondering if perhaps there are some mismatched DLLs or something like that.

How about this ... could you open a command prompt window, change into the NowSMS directory, then type DIR /s > FILE.TXT ... I'd like to see that FILE.TXT which shows the directory structure and files to see if anything looks unusual.

-bn
Anonymous
 
Posted on Saturday, October 08, 2005 - 03:39 am:   

Hi Bryce,
I've just uninstalled the whole NowSMS from my computer, checked that the directory was completely deleted, restarted the computer and installed it again. I got the 5.51b version installation. After adding the SMPP connection, I just add these 3 lines to the INI file:
ReceiptRequested=Yes
TrackSMPPReceipts=Yes
Debug=Yes
Sending a SMS from the Web interface and I got the SAME bug!!?And after copying the 5.51i patch to NowSMS I still got the bug!I'm using WinXP with SP1.
I dont send the NowSMS directory's content cause I got a clean install. I guess that during the SENDING of a SMS, something happened with NowSMS engine WHEN the option TrackSMPPReceipts IS ON and it dropped the connection and stuck in a loop. Maybe there is nothing to do with the RECEICVING of the receipt itself but the option may caused the engine to do OTHER preparation during the sending (like store the NowSMS msgID?) and THIS JOB was failed. Can you check it with your developers?
Thanks and BR
Levi}
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5115
Registered: 10-2002
Posted on Tuesday, October 11, 2005 - 04:48 pm:   

Hi Levi,

Could you open a command prompt window, change into the NowSMS directory, then type DIR /s > FILE.TXT ... I'd like to see that FILE.TXT which shows the directory structure and files to see if anything looks unusual.

I think I know what is happening, but I don't know why. Hence we're looking for clues ...

-bn
Anonymous
 
Posted on Thursday, October 13, 2005 - 05:07 am:   

Hi Bryce,
Here is the directory's content.Please inform me if you have traced the bug.
Thanks and BR
Levi
text/plain
file.txt (34.2 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5117
Registered: 10-2002
Posted on Thursday, October 13, 2005 - 03:46 pm:   

Hi Levi,

Thanks. I've managed to recreate the problem.

It seems to be related to NOT having the "Require Authentication for web interface" setting checked.

I have also been able to recreate the problem by restarting the service while there are queued messages, even if the above setting is checked. (But the sure fire way to trigger this problem is to submit some messages requesting a receipt, with TrackSMPPReceipts=On, and the above setting not checked.)

We're working on an update as I type this.

-bn
Anonymous
 
Posted on Friday, October 14, 2005 - 05:26 am:   

Hi Bryce,
I'm glad that you located the bug.It was annoying cause I know there are probably thousands of NowSMS users out there and the receipt track all worked for them but me.
BR Levi
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5133
Registered: 10-2002
Posted on Friday, October 14, 2005 - 04:21 pm:   

Hi Levi,

This is a new feature, so there aren't too many people using it yet. And it currently isn't documented anywhere other than threads here on the discussion board (not even in the readme). So, there were bound to be some problems, although this one surprises me quite a bit.

The purpose of only discussing it on the discussion board was to encourage this type of feedback from active users who would be ready to download another update as we worked out different issues.

I think it's been good, as we've gotten feedback about various different receipt formats, and the mysterious looping issue.

I've updated http://www.nowsms.com/download/latestpatch.zip with v5.51k. It fixes the problem that we were able to recreate, which I suspect is the same problem you are experiencing. So give it a try, and let me know.

-bn
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 56
Registered: 06-2004
Posted on Friday, October 14, 2005 - 10:00 pm:   

Hi levi!

I recall observing a strange problem awhile ago, which may have triggered the looping:

Open Task Manager and highlight the smsgws.exe entry. Leave the Task Manager running in foreground and go to NowSMS, change something (check and uncheck some feature so that the "Apply" button appears. Watching the smsgws.exe in task manager press "Apply." The service should disappear, appear again and stay there. In some cases (which was on one of our test machines with XP SP1) the service whoud start cycling on and off after such restart, and the only remedy was to reboot the server. Stopping the service and startng it again wasn't causing the same behaviour however.

If you observe this, your looping may have been happening due to these spurious restarts, which could be due to an OS bug, as we'ved never noticed the same with XP SP2.

Regards,
Ashot
Anonymous
 
Posted on Sunday, October 16, 2005 - 07:14 am:   

Hi Bryce,
Yes - it WORKS Now(SMS) - many thanks!
Just a note to Ashot: it wasn't my problem 'cause it did work before if I turned off the option TrackSMPPReceipts. Thanks anyway.
BR Levi
Anonymous
 
Posted on Monday, October 24, 2005 - 02:41 am:   

Hi Bryce,
I'm troubling you again with some feature to the product wish-list: As I tested with real SMPP servers, it seem that my operator SMPP server acknowledged the SMSs by SMSID both in hexadecimal and decimal format?! However, the delivery reports come back contains the decimal SMSIDs only. For this reason I got only half of the deleivery reports for sent SMSs. I guess that it is an operator-specific thing and nobody else got that problem?
It is possible to convert both the acknowleded SMSIDs and the SMSIDs in delivery reports to a specific format (hexa or decimal) and doing the matching afterwards?
Many thanks!
BR Levi
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5185
Registered: 10-2002
Posted on Tuesday, October 25, 2005 - 02:20 pm:   

Hi Levi,

I think I would need to see some examples of what is and is not working.

NowSMS treats its message id field as a text string. But we track upstream id's whether they are hex or decimal, and convert them to the text string id originally assigned by NowSMS. (NowSMS does use a hex value, but we don't consider it as such.)

Anyway, if something is not working, I believe we would need to see examples of what did or did not work. There might be yet another issue where an SMSC is doing something unusual that we did not consider.

-bn
Anonymous
 
Posted on Thursday, October 27, 2005 - 03:43 am:   

Hi Bryce,
Thanks for your quick response.I'm contacting my operator to track this prob.It may be their problem.Will let you know the result.
BR Levi
Yosi Oren
New member
Username: Nabulaer

Post Number: 7
Registered: 12-2004
Posted on Tuesday, November 15, 2005 - 09:35 am:   

Hi,
Also had the same problem with J patch.
Now tested with the K patch , no more loops !!!
Greate work guys !!!

Login Login / Register Logout Logout Search Last 30 Days Topics Topics