0

I have recently developed a GPRS communication software using Arduino (embedded application) and GSM modem to communicate to/fro from web server. However I found that there is enough delay and request getting dropped (response timeout) while receiving a response from server at client side.

The techniques I have tried are - TCP / UDP / HTTPS / HTTP.

In my case our requirement is for a Reliable, Fast, Guarantee Communication between client and server.

Please let me know which communication stack would establish the same or rather be best to be used?

Thanks in advance

Programmer
  • 8,303
  • 23
  • 78
  • 162
  • 1
    Reliable and Fast are at opposite ends of the spectrum. You'll get better bandwidth with UDP but you won't get guaranteed packet delivery. It depends on your application. – user3467349 Feb 21 '15 at 14:28

2 Answers2

1

GPRS gives you direct IP access to the Internet. If you're losing packets or suffering large delays when sending packets to your server then this sounds like a problem with the mobile ISP.

Ken Tindell
  • 343
  • 4
  • 7
  • The other thing to bear in mind is that GPRS is slow (CSD is 9.6kbit/s and even HSCSD is only 14.4kbit/s upload). The serial line to your modem will run a lot quicker, but the IP packets sent will go a lot more slowly. Have you done a quick calculation of the amount of data you're sending and looked at the specific class of GPRS your mobile ISP supports? You might simply be trying to send too much data in too short a time. – Ken Tindell Feb 23 '15 at 12:20
0

As Ken mentioned GPRS will provide you IP connectivity to the internet (or some private network if applicable).

On top of IP you can choose to use a number of higher layer protocols, the two most common of which are probably UDP and TCP.

UDP is 'connectionless' and provides very little in the way of error detection/correction etc.

TCP is connection orientated (which means that some signalling happens back and forth to establish a virtual 'connection' first). It also includes mechanisms to provide error detection, error correction and correct packet delivery order. TCP also includes flow control, to avoid the sender overloading the receiver, and congestion control to avoid network overload.

There is a perception that UDP is faster than TCP, but I think it depends on the situation - take a look at this discussion for some further discussion on speed, reliability etc between UDP and TCP (go down through all the high scored answers):

For your requirements, I would think a solution based on TCP/IP is probably what you want.

Whether you want to use HTTP or some other protocol on top of that is going to be dependent on your solution, and to some extent on personal preference.

Community
  • 1
  • 1
Mick
  • 24,231
  • 1
  • 54
  • 120
  • Thanks for the details - but for it takes around 2-5 seconds wait time to get a response? How can I reduce the same? – Programmer Feb 24 '15 at 07:14
  • Well, as Ken mentioned GRPS is not fast, but it should not really be that slow if your payload is small. It would be worth doing some testing to try to see where the delay is and to compare with other GPRS devices (and old phone on the same network and also different networks for example). If your messages are sent only occasionally then much of the delay could be the mobile setup (see this link: http://serverfault.com/a/573815). GPRS 'sessions' timeout when idle so will need to be set up again every time if you only have occasional messages. – Mick Feb 24 '15 at 10:06