Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Congestion Controll

Help
-]-[
2004-10-27
2013-05-21
  • -]-[
    -]-[
    2004-10-27

    Have a question about congestion controll in version 1.1

    In the gen_esme:handle_opperation call is it valid to give the following return value

    {ok, [{congestion_state, 99}]}

    In order to force the SMSC to slow down its delivery of messages?

    Why would I want to do this?  I am spawning a process for each message delivered to me.  During peak bursts it might be that I am spawning more processes than a set limmit.  I need to either slow down the delivery of messages, or stop receiving them for a while, untill some of the other procsses are done.

    If I understand congestion_status correctly, if it has a value over 90, the other end should try to delay its delivery somewhat.  The gen_esme_session actually drops messages that are delivered during a congested state.  This is not what I want from the SMSC.

    Does this mean that to be safe, I should rather delay the return of the gen_esme:handle_opperation call until a new process is available than use the congestion_state parameter?

    -]-[einrich

     
    • Hi,

      Yes, you can return {ok, [{congestion_state, 99}]} in response to gen_esme:handle_operation. 

      The parameters (of the PDU body) you explicitly set on the response parameters list are preserved by underlying layers, and that applies to the congestion_state parameter also.  If you set congestion_state to 99, that value should go all the way to the SMSC along with the response PDU, telling the SMSC to slow down as you intended.

      > The gen_esme_session actually drops messages ...

      Whenever the SMSC gets congested, if you try to submit a message to it, the gen_esme_session won't let you do so, and as a return value to that function call, you'll get {error, ?ESME_RTHROTTLED}.  ESME developers are responsible for handling this error response and retry that submission later on, discard it, or whatever.  Another approach could have been to send the message to the SMSC, even if we know it is congested, but I thought it was better not to keep on flooding the SMSC.  That's why gen_esme_session behaves like this.

      If it's you (the ESME), the one that is congested, gen_esme_session does not (shouldn't) drop any messages, it just advises the SMSC by sending the calculated self_congestion_state value (which at that point should be over 90, as you stated). 

      Best regards,

      Quique