Network.request timeout limit?

Solar2D General Questions/Discussion
#1

Hi,

We are currently using the network.request API to allow users to upload images to our servers. However in recent days we have received lots of reports saying that the upload feature isn’t working when attempted on an EDGE network connection. After some investigating we found that the network.request API only has a 30 seconds timeout limit? And that there is no way of increasing it for some reason? This has cornered us as we can not find any way of solving this bug now without a way of increasing the timeout limit.

Is there any particular reason as to why Corona users can not increase their timeout limits for the network.requests? Why is this set to a fix time and not adjustable? Is there any way to go around this? This is pretty critical to us since we have so many users depending on our upload feature and when it’s not working it can get really frustrating and even upsetting.

Would appreciate any ideas any one has on how we can solve this. Would also love a response as to why we can not choose to change the timeout limit for the network.request. It doesn’t seem logical to me why it’s unchangeable?

Sincerely
Mitatn
[import]uid: 14018 topic_id: 32865 reply_id: 332865[/import]

#2

+1 on this. This has caused me a bunch of problems too! [import]uid: 8872 topic_id: 32865 reply_id: 130737[/import]

#3

We use params.timeout, however we only shorten the duration rather then lengthen.

A solution could be to play around with LuaSocket (contained within Corona’s API, ref at:http://w3.impa.br/~diego/software/luasocket/reference.html), and use an LT12N File source with a blocking LuaSocket HTTP request. This would allow you to send the image in chunks(Don’t set the content-length, it’ll default to a Chunked request which is what you want), and therefore minimize the timeout chances, since each individual chunk is sent with a timeout, rather than the whole file. The downside is that this is a main thread blocking request, and so you’d also want to provide some sort of activity indicator, since your app is going to freeze during the transfer(If you don’t want a blocking request, the next step is to do the same thing directly with a TCP socket, this way you can fill the buffer, wait, fill it again until the whole thing is sent over multiple frames).

Ideally this is what you should be doing anyway, since providing a very long timeout to transfer large files rather than processing those files in chunks, means it’s much harder to react to a dropped or bad connection, since it’ll be a long time before you know something went wrong.
[import]uid: 134101 topic_id: 32865 reply_id: 130739[/import]

#4

+1 on this. This has caused me a bunch of problems too! [import]uid: 8872 topic_id: 32865 reply_id: 130737[/import]

#5

We use params.timeout, however we only shorten the duration rather then lengthen.

A solution could be to play around with LuaSocket (contained within Corona’s API, ref at:http://w3.impa.br/~diego/software/luasocket/reference.html), and use an LT12N File source with a blocking LuaSocket HTTP request. This would allow you to send the image in chunks(Don’t set the content-length, it’ll default to a Chunked request which is what you want), and therefore minimize the timeout chances, since each individual chunk is sent with a timeout, rather than the whole file. The downside is that this is a main thread blocking request, and so you’d also want to provide some sort of activity indicator, since your app is going to freeze during the transfer(If you don’t want a blocking request, the next step is to do the same thing directly with a TCP socket, this way you can fill the buffer, wait, fill it again until the whole thing is sent over multiple frames).

Ideally this is what you should be doing anyway, since providing a very long timeout to transfer large files rather than processing those files in chunks, means it’s much harder to react to a dropped or bad connection, since it’ll be a long time before you know something went wrong.
[import]uid: 134101 topic_id: 32865 reply_id: 130739[/import]