Yes, all of that makes sense. I'm still wondering what the best solution
would be to determine which address to tell to the other client.
And the answer is....
DON'T tell the other client. Let the other client get the info for
themselves from their own network stack.
Sending your own IP address over the network as part of your payload
is ALWAYS WRONG.
1) you don't know your IP address. You can jump through hoops and
maybe correctly determine what it was when it left your machine,
2) you don't know what happens between you and the other end of the
connection. The IP address in the _packet header_ might be changed
several times between you and the other end of the trip. This is how
NAT works, but NAT isn't the only thing that may do this.
3) you don't need to know your IP address. If the packet gets to the
other end, the other end ALREADY knows how to talk to you, they get
the return address as part of the header of the packet they received.
4) you're just wasting bandwidth. Your IP address, or more
accurately, an address that the remote end can use to talk back to
you, is already in the header. Putting it in the packet just
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden