Async mode

Async mode SearchSearch
Author Message
Alex Kaiser
Frequent Contributor
Username: Alex_k

Post Number: 263
Registered: 07-2006
Posted on Thursday, December 08, 2011 - 02:26 pm:   

Hi Des,

Could please explain, "WindowSize" parameter means that NowSMS send and receive messages in async mode? or only submitting?

Regards,
Alex K.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3668
Registered: 08-2008
Posted on Friday, December 09, 2011 - 06:49 pm:   

Hi Alex,

This parameter only applies to sending.

It refers to the maximum number of messages that can be transmitted to another server without receiving an acknowledgment.

--
Des
NowSMS Support
Alex Kaiser
Frequent Contributor
Username: Alex_k

Post Number: 264
Registered: 07-2006
Posted on Saturday, December 10, 2011 - 09:24 am:   

Hi Des,

But how to enable NowSMS receive DRs in async mode?

Regards,
Alex K.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3671
Registered: 08-2008
Posted on Wednesday, December 14, 2011 - 09:13 pm:   

Hi Alex,

It is a little confusing, but whatever side of the connection is sending or delivering the messages is the one that determines whether or not async mode is being used.

Let me explain with two scenarios.

Scenario #1: NowSMS is an SMPP client. The SMPP connection is defined in the NowSMS "SMSC" list.

When NowSMS is transmitting messages over this SMPP connection, it can enable async mode for messages that it transmits/sends to the SMPP server. (This is enabled with the async mode/window size configuration settings in NowSMS, with which you are already familiar.)

For the reverse direction, inbound messages from that SMPP server to NowSMS (including delivery reports) the SMPP server is in control over whether or not async mode is used in that direction.

Whether it's a transmitter, receiver, or transceiver, whichever sending is transmitting or delivering messages to the other side of the connection, is independently responsible for determining whether or not async mode is being used in that direction.

Async mode might be used by one end for transmitting or delivering messages, but not by the other end for message transmission in the other direction.

Scenario #2: NowSMS is an SMPP server. The SMPP client account that is allowed to connect to NowSMS is defined in the NowSMS "SMS Users" list.

The SMPP client controls whether or not async mode is used to transmit messages to NowSMS. NowSMS requires no configuration for allowing or disallowing it (other than limiting the speed).

NowSMS controls whether or not async mode is used to deliver messages (and delivery reports) back to the client. (Parameter settings described here: http://www.nowsms.com/smpp-async-mode)


I believe you are referring to the first scenario.

If NowSMS is receiving delivery reports from another SMPP entity, whether or not async mode is used is a function of that other SMPP entity.

I point out both scenarios to explain how it relates to both client and server roles.

In various SMPP implementations, async mode is usually a focus for outbound message delivery, but an afterthought for inbound delivery back to SMPP clients.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3678
Registered: 08-2008
Posted on Thursday, December 15, 2011 - 09:05 pm:   

Hi Alex,

We've been running a series of performance tests this week, and there was a change introduced in the 2011.11 versions that caused a serious performance limiting problem, especially for transceiver connections when high volumes of messages are being sent and received simultaneously.

An update has been posted at http://www.nowsms.com/download/nowsms20111215.zip to correct this problem.

--
Des
NowSMS Support
Alex Kaiser
Frequent Contributor
Username: Alex_k

Post Number: 265
Registered: 07-2006
Posted on Friday, December 16, 2011 - 03:00 pm:   

Hi Des,

Thank you for the update, we'll test it. Anyway, I think there's still a problem with file locking, especially on virtual environments.

Regards,
Alex K.