2 way sms call to script

2 way sms call to script SearchSearch
Author Message
Bipin Chandra
New member
Username: Xbipin

Post Number: 18
Registered: 05-2009
Posted on Sunday, July 12, 2009 - 04:07 pm:   

here is what i have understood till now in 2 way sms, when the delivery report comes to nowsms from the SMPP connection, it runs the provided URL to post to the script the delivery report, now my script is in php which takes the post from nowsms and updates in the db the status of the message.

what i wanted to know was under what conditions will nowsms, while posting to link the report, actually keep the report in its inbox and retry later?

i mean if i generate a 404 by my script or any such HTTP header then will nowsms not consider the post successful and then retry later or it will in any case consider the post successful and remove it from inbox?

i wanted to know this because if the webserver hosting the script goes down or due to some latency or something like that the receipt id generated by the SMS psot to nowsms takes time to be stored in the db and if the delievery reports comes quick enough then my script will fail to updates status of a sent message coz the receipt id wont be in the db so during that time i can make it generate a specific http response header making nowsms try later on.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1036
Registered: 08-2008
Posted on Monday, July 13, 2009 - 09:53 pm:   

Hi,

If the server doesn't respond with a valid HTTP header, then the message will be retried.

If the HTTP response is valid, but the return code is not OK, NowSMS renames the file in the SMS-IN directory with a .BAD file extension. It is possible to rename it back with an .IN extension to force the message to be reprocessed.

--
Des
NowSMS Support
Bipin Chandra
New member
Username: Xbipin

Post Number: 19
Registered: 05-2009
Posted on Tuesday, July 14, 2009 - 06:54 am:   

is it possible to not make it rename to BAD at all and retry after some time when it receives as valid HTTP header which is not ok.

and what response would it be when u say "If the server doesn't respond with a valid HTTP header, then the message will be retried"
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1041
Registered: 08-2008
Posted on Tuesday, July 14, 2009 - 03:32 pm:   

Several years ago, we did things differently.

If the HTTP response was a 400 (not found) or 500 (internal error) series response, we would retry the command.

This caused a lot of problems for some users. In particular, we found that 500 series errors were very common if an ASP script encountered something unusual.

In many cases, the ASP script didn't even realise that anything was wrong ... it just kept on getting the same message sent to it over and over again.

We had so many support issues over this, that we had to change this behaviour.

Unfortunately, we didn't leave any configurable settings for different options of how to handle this situation.

We left it so that if the server was down, and we couldn't connect to it, then retries would be triggered.

Similarly if the HTTP response is not valid, it will be retried.


quote:

and what response would it be when u say "If the server doesn't respond with a valid HTTP header, then the message will be retried"




An HTTP response always starts with a status line, like this:

HTTP/1.1 200 OK

HTTP/1.0 404 Not Found

If the response doesn't start with "HTTP" ... or doesn't have a numeric over code after "HTTP/x.x", then it's not valid.

You raise a good point, we should probably revisit the way this scenario is handled, and make it configurable.

One of the problems with the past behaviour was that there was no maximum limit on the number of retries, and there was no delay between retry attempts. If we introduced retry delays and a limit on the number of retry attempts, this could be useful.

Unfortunately, right now, it only works the way that I described.

--
Des
NowSMS Support
Nikos Mavrakis
New member
Username: Nmavra

Post Number: 12
Registered: 05-2007
Posted on Wednesday, July 15, 2009 - 02:47 pm:   

Hello Des,
I agree with Bipin that we should somehow be able to configure it differently.

This is my scenario that happened 2 days ago. We had a very large amount of xxxxxx.in and yyyyyy.rec messages in the SMS-IN folder because something was wrong with our IIS server serving aspx pages. While we had this problem, the incoming messages where stuck in this folder and in a few hours they were around 9500 files.

When I did an iisreset, most of these files became .BAD, around 1000 files became BAD until the IIS was reset. Then after a while, I did an iisreset again and this gave me another 1000 BAD files.

We have only noticed this 2 days ago, but in the past we have been doing iisresets a few times so I assume we have been losing some messages. Although the impact was not so big (since when everything operates normally only about 30 msgs become BAD until IIS is reset), I believe this should be configurable.

Sorry for the long post, I just wanted to let you know of a situation where this behavior caused a bit of an issue. For the record, we had to rename all files back to .in and .rec, depending on whether they were delivery reports or normal sms traffic.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1047
Registered: 08-2008
Posted on Wednesday, July 15, 2009 - 05:58 pm:   

That's a good point Nikos.

I'll have to bring up in our engineering discussions with greater urgency.

And just to let you know, it is not necessary to selectively rename *.BAD to *.IN or *.REC depending on the message type.

Regardless of whether or not it is a receipt, NowSMS will process it correctly if it has either a *.IN or *.REC extension. There is just one group of 2-way threads looking for *.IN messages and one group looking for *.REC. But both groups perform the exact same processing.

--
Des
NowSMS Support
Nikos Mavrakis
New member
Username: Nmavra

Post Number: 15
Registered: 05-2007
Posted on Thursday, July 16, 2009 - 08:28 am:   

Thanks for your attention Des, I believe all us who use IIS as a web server are looking forward to it! :-)

The clarification about .rec and .in extensions and processing is also helpful, I didn't know that!