[GH-ISSUE #26] HTTP server to push SMS

kerem commented

2026-02-28 01:22:47 +03:00

Owner

Originally created by @sarbogast on GitHub (Jul 14, 2012).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/26

It would be really nice if SMSSync could also act as a mini HTTP server and wait for POST requests itself instead of polling the server for tasks. SMS gateway does that and it's really useful. Your app is so much better (thanks a lot for SMSSync by the way).

Originally created by @sarbogast on GitHub (Jul 14, 2012). Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/26 It would be really nice if SMSSync could also act as a mini HTTP server and wait for POST requests itself instead of polling the server for tasks. SMS gateway does that and it's really useful. Your app is so much better (thanks a lot for SMSSync by the way).

kerem closed this issue

2026-02-28 01:22:47 +03:00

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@saratovout commented on GitHub (Aug 18, 2012):

Personally, I am opposed to this change.
External IP operator typically change frequently and are issued on a user's session. The function will be useless.

@saratovout commented on GitHub (Aug 18, 2012): Personally, I am opposed to this change. External IP operator typically change frequently and are issued on a user's session. The function will be useless.

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@ghost commented on GitHub (Aug 21, 2012):

I'd like this but with frequent enough polling and fixed task checking reliability it's not a high priority for me.

The dynamic IP problem is easy to go around as there are android clients that are compatible at least with many popular dynamic DNS services.
Another way to circumvent the problem would be to have SMSSync publish the host phone's IP address to the sync url, but I think the DNS approach makes more sense.

@ghost commented on GitHub (Aug 21, 2012): I'd like this but with frequent enough polling and fixed task checking reliability it's not a high priority for me. The dynamic IP problem is easy to go around as there are android clients that are compatible at least with many popular dynamic DNS services. Another way to circumvent the problem would be to have SMSSync publish the host phone's IP address to the sync url, but I think the DNS approach makes more sense.

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@bodo commented on GitHub (Nov 9, 2012):

VPN tunnel is another more reliable solution to turn the phone app into a server. By this you don't need dyndns and SMSSync don't need to listen as a service. Secondly mobile phone carrier might block incoming connections always or on some ports. I even heard of nat translation in some networks making servers running on the phone without VPN just impossible.
But beside the technical possible solutions I think you will replace your mobile as a SMS gateway with a service provider sooner or later. On high throughput this is not reliable and most likely too expensive. SMS on your carrier bill cost usually too much. Even this "unlimited SMS packages" have limits requesting fair / normal private use / non excessive etc. or they catch you by stating that you disturb the normal network operation.
So give this a low priority and with an adjustable polling you can archive a similar function that is more likely to work in real life.

@bodo commented on GitHub (Nov 9, 2012): VPN tunnel is another more reliable solution to turn the phone app into a server. By this you don't need dyndns and SMSSync don't need to listen as a service. Secondly mobile phone carrier might block incoming connections always or on some ports. I even heard of nat translation in some networks making servers running on the phone without VPN just impossible. But beside the technical possible solutions I think you will replace your mobile as a SMS gateway with a service provider sooner or later. On high throughput this is not reliable and most likely too expensive. SMS on your carrier bill cost usually too much. Even this "unlimited SMS packages" have limits requesting fair / normal private use / non excessive etc. or they catch you by stating that you disturb the normal network operation. So give this a low priority and with an adjustable polling you can archive a similar function that is more likely to work in real life.

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@eyedol commented on GitHub (Jun 27, 2013):

@sarbogast @ashowtimes @agenttihirvinen @bodo @mandric From the comments above, I think the best approach is to increase the frequency rate? At the moment it's set to 1 minute the earliest. Add 5s, 10s, 15s, 20s, 30s,50s? I'm afraid this might kill battery or even lower performance as the ping will happen more frequent. I have had users ask for this request.

What do you guys think?

@eyedol commented on GitHub (Jun 27, 2013): @sarbogast @ashowtimes @agenttihirvinen @bodo @mandric From the comments above, I think the best approach is to increase the frequency rate? At the moment it's set to 1 minute the earliest. Add `5s`, `10s`, `15s`, `20s`, `30s`,`50s`? I'm afraid this might kill battery or even lower performance as the ping will happen more frequent. I have had users ask for this request. What do you guys think?

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@saratovout commented on GitHub (Jun 27, 2013):

@eyedol allow the user to set any integer number of minutes as a parameter.

Implement Push Notifications is also questionable, since most servers do not yet support the implementation of this normal. Especially, I am opposed to the usual frequent requests (with a frequency of less than one minute).

@saratovout commented on GitHub (Jun 27, 2013): @eyedol allow the user to set any integer number of minutes as a parameter. Implement Push Notifications is also questionable, since most servers do not yet support the implementation of this normal. Especially, I am opposed to the usual frequent requests (with a frequency of less than one minute).

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@eyedol commented on GitHub (Jun 27, 2013):

@ashowtimes Thanks. Noted. Just enter the minute you want instead of selecting a predefined one. no support for seconds because of performance.

@eyedol commented on GitHub (Jun 27, 2013): @ashowtimes Thanks. Noted. Just enter the minute you want instead of selecting a predefined one. no support for seconds because of performance.

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@ghost commented on GitHub (Jul 30, 2013):

Related: When the server is pushing a large number of messages out, there have been intermittent cases of messages having been dropped. I think it is more likely when those messages are longer(multipart sms). I have had to limit the number of messages the server will give out at a time, but it is quite inconvenient that it also introduces an unnecessary delay also to short messages or much more complicated analysis of what smssync can handle(on a given phone) and adapting to that.

Of course, unless SMSSync will confirm after task checking that it has received all the messages given to it by the server, and I can absolutely trust that SMSSync itself will not choke on a large number of large messages, I will still have to limit the server's task-checking response size to minimize the chance of hitting SMSSync's task checking requests timeout even when the network is slow.

However, if task checking had an extra option: "If there are unsent messages, do not check for tasks until there are none", I could set a very small interval, have simple output limiting, so batches of small messages would still go out quickly, and even with long multipart messages SMSSync wouldn't get messages to send at a rate large than it can handle.

Then again, while we have to do some limiting server-side, it would be desirable to both

Conserve battery by not polling too frequently
Get the messages waiting on the server out asap.

I think a good solution could be that if the server has more messages queud than it returns in the response, it would include a signal that there are more messages queued on the server. Then SMSSync could send out the messages received, and immediately after that make another task check even if it not yet the time for the next scheduled task check.

Actually, I think these two together would allow almost push-like delays without being terribly hard on the battery or performance:

Task check interval 60 s.
Request timeout 60 s.
Server gets task check request. Server has no messages queued, so it waits and checks every second until just before expected timeout.
At 30 seconds, someone does something on the internets, so a message is queud.
At 31 seconds, this message is passed to SMSSync with the note "More messages in queue." (Alternatively "Please do another check immediately after doing these tasks.")
SMSSync resets the time of the next sync to be 60 s from now, and makes a new task checking request.

Alternatively:
...
4. Just before expected timeout, server replies "no tasks"
5. A new task check request is made.

With this model, there would be only one request and one response per minute if there are no messages, and almost all the time we will have almost realtime relaying of messages when tere are.
Contrast this to the current model, where a 5 s check interval would result in 12 request-response pairs per minute even when nothing is happening.

@ghost commented on GitHub (Jul 30, 2013): Related: When the server is pushing a large number of messages out, there have been intermittent cases of messages having been dropped. I think it is more likely when those messages are longer(multipart sms). I have had to limit the number of messages the server will give out at a time, but it is quite inconvenient that it also introduces an unnecessary delay also to short messages or much more complicated analysis of what smssync can handle(on a given phone) and adapting to that. Of course, unless SMSSync will confirm after task checking that it has received all the messages given to it by the server, and I can absolutely trust that SMSSync itself will not choke on a large number of large messages, I will still have to limit the server's task-checking response size to minimize the chance of hitting SMSSync's task checking requests timeout even when the network is slow. However, if task checking had an extra option: "If there are unsent messages, do not check for tasks until there are none", I could set a very small interval, have simple output limiting, so batches of small messages would still go out quickly, and even with long multipart messages SMSSync wouldn't get messages to send at a rate large than it can handle. Then again, while we have to do some limiting server-side, it would be desirable to both 1. Conserve battery by not polling too frequently 2. Get the messages waiting on the server out asap. I think a good solution could be that if the server has more messages queud than it returns in the response, it would include a signal that there are more messages queued on the server. Then SMSSync could send out the messages received, and immediately after that make another task check even if it not yet the time for the next _scheduled task_ check. Actually, I think these two together would allow almost push-like delays without being terribly hard on the battery _or_ performance: 1. Task check interval 60 s. 2. Request timeout 60 s. 3. Server gets task check request. Server has no messages queued, so it waits and checks every second until just before expected timeout. 4. At 30 seconds, someone does something on the internets, so a message is queud. 5. At 31 seconds, this message is passed to SMSSync with the note "More messages in queue." (Alternatively "Please do another check immediately after doing these tasks.") 6. SMSSync resets the time of the next sync to be 60 s from now, and makes a new task checking request. Alternatively: ... 4. Just before expected timeout, server replies "no tasks" 5. A new task check request is made. With this model, there would be only one request and one response per minute if there are no messages, and almost all the time we will have almost realtime relaying of messages when tere are. Contrast this to the current model, where a 5 s check interval would result in 12 request-response pairs per minute even when nothing is happening.

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@eyedol commented on GitHub (Aug 26, 2013):

@agenttihirvinen sounds like a good solution. I like the idea of the server telling SMSSync there are more messages queued up. Partial responses are good. This way, it won't choke SMSSync to send more messages than it can.

Sample JSON when there are more messages queued up.

{
    "payload": {
        "success": "true",
        "task": "send",
        "more": "true",
        "messages": [
            {
                "to": "+000-000-0000",
                "message": "the message goes here" 
            },
            {
                "to": "+000-000-0000",
                "message": "the message goes here" 
            },
            {
                "to": "+000-000-0000",
                "message": "the message goes here" 
            }
        ]
    }
}

One way to stop abuse of this feature, if more is true and there are no messages to be sent, SMSSync will stop immediate triggering of the Task Check feature.

@eyedol commented on GitHub (Aug 26, 2013): @agenttihirvinen sounds like a good solution. I like the idea of the server telling SMSSync there are more messages queued up. Partial responses are good. This way, it won't choke SMSSync to send more messages than it can. Sample JSON when there are more messages queued up. ``` javascript { "payload": { "success": "true", "task": "send", "more": "true", "messages": [ { "to": "+000-000-0000", "message": "the message goes here" }, { "to": "+000-000-0000", "message": "the message goes here" }, { "to": "+000-000-0000", "message": "the message goes here" } ] } } ``` One way to stop abuse of this feature, if more is true and there are no messages to be sent, SMSSync will stop immediate triggering of the `Task Check` feature.

kerem commented

2026-02-28 01:22:48 +03:00

Author

Owner

@eyedol commented on GitHub (Apr 17, 2015):

This should be solved by the message result api. Closing for now.

@eyedol commented on GitHub (Apr 17, 2015): This should be solved by the message result api. Closing for now.

Rows
Columns

[GH-ISSUE #26] HTTP server to push SMS #20