IP Address for Socket Server and Client

Question

Created 1w

Replies 4

Boosts 0

Participants 2

I am developing an App using the Networking framework, which can be either a Socket Server or a Socket Client, such that 2 devices can communicate remotely. For the most part I have it working, except:

I am not sure of the best way to determine the IP Address for the Socket Server in order to allow the Client app to connect. I am currently using either of Cloud Functions, or lookup webpages (such as ipify.org) and even reading the IP addresses locally from within the device (this returns many, but not all of them connect successfully). These options seem to work if the Socket Server app is connected to the internet with an IPv6 address, but I find that when the Socket Server app is connected with an IPv4 address, the Client app never successfully connects.

How should I: a) force the Socket Server app to have/use an IPV6 address at all times? or b) allow the Client app to connect successfully via an IPv4 address?

And is there a simple way to know what IP Address the Socket Server is listening from?

Boost

Answer 1

DTS Engineer OP

Apple

1w

This question, and the question in your other thread, suggest that you’ve misunderstood how networking works on the modern Internet. Before I suggest a path forward, I’d like to make sure I understand your overall goal.

My reading of your question is that:

You’re building an app for Apple platforms.
You expect this app to be run by two different users…
… on two different devices…
… which can be anywhere on the Internet.
You want to exchange UDP datagrams between those instances of your app.

Is that correct?

If so, what Apple platforms are you targeting?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

TamarackBob OP

1w

Hi Quinn You could be right on the misunderstanding of modern networking. I wrote my first socket code in early 1990s. But for this app I'm keen to use the most up-to-date solution possible.

Yes. Apple platforms only.
Yes. Two separate users...
Yes. Two separate devices...
which could be in completely different continents.
My app doesn't really justify TCP so I chose UDP (for speed, and because TCP ended up needing an NWProtocolFramer due to it combining multiple messages together.)

Currently I am only targeting iOS.

0

Answer 3

DTS Engineer OP

Apple

1w

Right, so achieving these goals is a serious challenge. The problem is that device-to-device connections are often not feasible on the modern Internet. The canonical blocker here is NAT.

Imagine you have two devices, A and B, and they’re both behind a NAT. Each device has a private IP address, for example, something on the 192.168.0.0/16 network. When A makes an outgoing connection, the NAT establishes a mapping between A’s private source IP and port and the NAT’s public IP and port. Prior to A making that connection, this mapping doesn’t exist, so B can’t make an incoming connection to A.

In the case of NAT there are well-known techniques to get around this (see NAT traversal) but those only work in specific circumstances. And NAT is not the only challenge here. These days the Internet is full of middleboxen, and those prevent this sort of device-to-device connection in general. And don’t get me started on proxies |-:

Note The reason why you’re seeing this work in the IPv6 case is that IPv6 has lots of addresses and so doesn’t rely on NAT. However, that’s not a solution in general. Not all networks support IPv6 and, even if they do, these connections can be block by some other middlebox, like a firewall.

As to what you should do, that depends on the nature of your product. Is this a game perchance?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

TamarackBob OP

1w

Thanks Quinn for the explanation. It all makes sense.

My app is not a game, but in simple terms it requires one user to send a small amount of data to another user (possibly remote), on a regular basis (maybe every 5-10 seconds?). I have a working prototype which uses Google Firebase to transfer this data via "documents" in an online database, but of course this has an associated cost.

My hopes were that a socket (or some other mechanism) could provide this functionality for free. The solution doesn't have to be serverless, but should be as cost free as possible.

0