0

I have an IoT edge device which is currently configured as a TCP server; the device gathers and processes some data, and then passes it to the connected clients. This works as intended when the server and client(s) are on the same network.

However, the above represents only one of four possible use cases:

  1. Edge device and client(s) on the same network (as per above).
  2. Edge device connected to internet via modem/router, with client(s) on a different network.
  3. Edge device connected to internet via mobile phone hotspot, with client(s) on a different network.
  4. Edge device connected to internet via 4G dongle, with client(s) on a different network.

In case 2 above, I understand how the process in case 1 can be applied, by establishing port forwarding on the edge device's connected modem/router and using the network's public IP address. However, from my understanding, port forwarding is unavailable (for all intents and purposes) when using a mobile hotspot connection. Similarly, 4G dongle carriers don't (typically) provide a public IP address, so routing a TCP connection to the edge device server wouldn't work in this case either.

What options are available which would allow for client-server TCP connections for all four use cases? For additional context and consideration, the TCP data will also need to be secured/obfuscated. Additionally, the data is time-sensitive, so ensuring minimal delay between transmission of the data from the server and reception of the data by the client(s) is paramount.

4
  • Please specify "minimal delay" - milliseconds? Tenths of seconds? Seconds?
    – Zac67
    Mar 23 at 8:38
  • Ideally less than the 20ms, but I would accept up to 500ms if there were no lower latency alternative.
    – jars121
    Mar 23 at 8:40
  • "less than 20 ms" excludes any transfer across WAN. 500 ms is certainly possible across WAN and cloud.
    – Zac67
    Mar 23 at 9:02
  • Ok great, I can work with that. Thanks for clarifying.
    – jars121
    Mar 23 at 9:05
2

One option is to use an intermediary rendezvous server in the cloud, and all devices connect to it.

There are several options for encryption, but we’d need more details before recommending something.

7
  • Thank you for the suggestion; I've since done some further reading on this possibility. The transmission/reception of the data is time sensitive (a consideration which I left out of the original post, my apologies); so a rendezvous/relay server approach probably isn't suitable. A direct peer-to-peer connection would definitely be preferable.
    – jars121
    Mar 23 at 4:34
  • 1
    @jars121 You cannot connect into a private network without port forwarding/destination NAT. A rendezvous server ("cloud") is your only option.
    – Zac67
    Mar 23 at 8:32
  • 1
    STUN might work in some networks, but only a fraction without prior configuration.
    – Zac67
    Mar 23 at 8:40
  • 1
    @jars121 how much delay can you accept? You mention 500 mS in your question. That’s certainly doable.
    – Ron Trunk
    Mar 23 at 11:43
  • 2
    @jars121 STUN is a generic way to set up port forwarding (as far as permitted by policies). If you've got port forwarding you don't need STUN.
    – Zac67
    Mar 23 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.