3

I'm working now on project related to remote car management.

We have some device able to start / stop car engine, provide GPS coordinate, check door lock status and so on. This device has SIM card installed.

Second side is a server which should communicate with device and allow consumers to manage their cars via iPhones, Androids and WM7 phones.

The main question for me now is what technical requirements should be defined for communication between device and server.

Anybody knows is there any books or articles about standard design patterns for such kind of data transport?

Here below is an example of problem annoying me

We need to send some requests to device (e.g. "start the car" or "give me a mileage"). In order to provide it server should have an address where it should to send this request.

If I understand right there are following ways to do it:

  • Organize VPN (expensive)
  • Use SMS transport (expensive)
  • Organize persistent session between device and server using TCP sockets (I have no idea whether it will work in Russian GSM network realities)

Maybe there is somebody here who has similar expertise and could give an advice where I should move?

Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265
Alexander Dimchenko
  • 31
  • 3
  • I don't have a resource that talks specifically about your problem. nonetheless, I'd suggest you to consider long-polling (the car request periodically for commands to your server and sends some data -every 5 seconds or so-, depending on your SIM data plan it could be really affordable) – SDReyes Dec 18 '12 at 14:50
  • Thank you for response! do you have any information about traffic consuming in such case (making request via TCP each n secs) ? – Alexander Dimchenko Dec 20 '12 at 06:10

1 Answers1

2

Resources

  • Design a service layer according to these principles

  • You can keep alive your TCP connection to reduce connection costs. then the long polling cost is minimum.

  • You can check ZeroMQ, it seems like an appropriate pub/sub server for your project

Costs

  • a message asking for pending commands and an empty response from the server (which will be more than 99.9% of your conversations) could be reduced to a single byte per request and another per response. so making a polling every ten seconds, we have:

    (20byte TCP framing ) + 1 byte/message * ( 1 request + 1 response ) * 6messages/1min * 60min/hour * 720hour/month = 10.8Mb per month needed to use long polling

  • Now, you add the cost of sending user commands from the server to the device (they are relative rare in comparison with the long polling messages):

    1 kbyte/message * ( 1 request + 1 response ) * 20messages/day * 30day/month = 1.2Mb per month needed to support user commands

  • Finally, you have to decide what data you want to collect -GPS, doors sensors, etc- and how often -1min, 10min, hourly, etc- that will sum up to the long polling costs = let's say 12MB

Total costs: Around 24Mb per month

Community
  • 1
  • 1
SDReyes
  • 9,798
  • 16
  • 53
  • 92
  • 1
    Hm, are they only charging for the actual payload/data and not TCP/IP framing? TCP header is 20 bytes, and then the underlying layers probably adds some more framing I guess. Just curious. – Jakob Möllås Dec 21 '12 at 07:37
  • Any other consideration you have, Jakob? – SDReyes Dec 23 '12 at 01:28
  • 1
    Yes, I would probably use UDP instead, especially since all packets will be very small and thus would fit into single frames. Using UDP gets rid of the connection dilemma you would otherwise end up with; the server will have to keep a lot of open connections, keep track of dead connections, reconnect etc. The long-polling would work fine over UDP as well as far as I can see. Think MMO game. Interesting problem though! – Jakob Möllås Dec 23 '12 at 06:56