Member Avatar for GH23

I'm developing an app that will be sending data back to a server every minute. Along with this data it will also be possible that someone running a program from a computer can updata the data in the database. When they update the data in database I will need to send the new info to the device. I was planning on doing this via long polling, but as I understand it this would require me to setup a second connection to send the data off every minute.

How would you suggest opening a data connection between a device and a server so that data can be transfered both ways? Keep in mind that the IP address of the device might be unmapble due to GPRS and that the IP address might change via tower hopping.

  • 2 Contributors
  • 2 Replies
  • 74 Views
  • 21 Hours Discussion Span
  • Latest Post Latest Post by GH23

Dani AI

Generated

Quick summary for (and responding to ): a device behind carrier NAT and tower hopping cannot reliably accept inbound connections, so the device must initiate and maintain the path the server will use to push messages. For a 1-minute telemetry cadence plus occasional server->device updates, the two practical patterns are (A) a single persistent device-initiated connection that carries both directions, or (B) periodic HTTP requests (polling/long-poll) where the device either (1) posts telemetry and the server immediately returns any pending commands, or (2) keeps a second long-poll open for pushes. Option A is more efficient and gives true server push without a second connection.

Recommended approach: use a lightweight broker/protocol (MQTT is designed for this: device publishes telemetry and subscribes to a device-specific topic for commands) so you get a single TCP/TLS session per device and reliable broker delivery. See MQTT for protocol ideas and brokers: MQTT.

Practical implementation notes and pitfalls:

  • Keepalive/heartbeat: implement an app-level ping (30-60s or tuned to carrier behavior). Do not rely solely on TCP keepalive.
  • Reconnect strategy: detect link loss, reconnect with exponential backoff, re-subscribe and resume. Persist unsent messages locally with unique IDs to avoid duplication.
  • Security: use TLS, mutual auth or token expiry and reauth on reconnect.
  • WinMo 6.5 specifics: there are fewer off-the-shelf libraries; either use a Compact Framework MQTT client or a tiny custom TCP framing protocol over sockets. Test behavior through carrier NAT and simulate tower handoff.
  • Fallbacks: if push must be guaranteed and TCP cannot be kept, plan an SMS or out-of-band alert as backup.

Minimal reconnect loop (pseudocode):

connect()
while connected:
  send_telemetry()
  if incoming_command(): handle()
  send_heartbeat()
on error:
  wait_backoff()
  reconnect()

Server-side should use durable queues and a broker so commands survive device downtime.

Recommended Answers

All 2 Replies

Member Avatar for peter_budo

What mobile platform you thinking to use? (Android, iOS, Qt, Windows)

Member Avatar for GH23

We are using Windows mobile 6.5. More specificly we are developing for Motorola's MC65.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.