HTTP server to push SMS about smssync

[saratovout]

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.

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.

[bodo]

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.

[eyedol]

@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?

[saratovout]

@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).

[eyedol]

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

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.

[eyedol]

@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]

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