IP address for a socket service

[paal.andreassen]

I have a problem. I have two instances of a client-server application
running on two different machines A and B.

A has a listening service, that listens for connections from B
B has a listening service, that listens for connections from A

The problem is what IP to bind the listening service to. I can find
all local ip-addresses this way:


IPHostEntry hostEntry =
Dns.GetHostEntry(Dns.GetHostName());

foreach (IPAddress ipAdress in hostEntry.AddressList)
{
Console.WriteLine(ipAdress.ToString());
}

But how on earth do I know which one to bind and listen to? There's a
mix of IPv4 and IPv6 addresses, virtual vmware addresses, one from the
wireless wifi card and one from the ethernet cable.

Argh...

The server component I'm using has a single "void Listen(string ip,
int port)" method. Even if I manage to listen on all addresses, how
will B know which one of A's to connect to? A sends B it's ip-address
using a different schema (but's it in a common database). But I still
need to put A's "external" address down.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi

There is an overload of the constructor of TcpListener that let you select
the IP, even more the variant where you only select a port is marked as
deprecated.
If no IP is especified it will use all the IPs in the system.

Of course the client has to know the ip or the name of the server, otherwise
it's imopssible to establish a communication.

 

[Chris Shepherd]

I have a problem. I have two instances of a client-server application
running on two different machines A and B.

A has a listening service, that listens for connections from B
B has a listening service, that listens for connections from A

The problem is what IP to bind the listening service to. I can find
all local ip-addresses this way: [...]
But how on earth do I know which one to bind and listen to? There's a
mix of IPv4 and IPv6 addresses, virtual vmware addresses, one from the
wireless wifi card and one from the ethernet cable.

Yup. Knowing which one to bind to depends on the network you want to listen on.
If A is publishing its IP to B, then it really doesn't matter what B publishes
on does it? You could just create your IPEndPoint using IPAddress.Any as the
IPAdress argument to just grab whatever the system thinks is best, i.e.:

Int32 port = 10101;
IPEndPoint myEndPoint = new IPEndPoint(IPAddress.Any, port);



Chris.

 

[Ben Voigt [C++ MVP]]

on does it? You could just create your IPEndPoint using IPAddress.Any as
the
IPAdress argument to just grab whatever the system thinks is best, i.e.:

On client-side, IPAddress.Any lets the system choose one (and only one). On
server side, though, IPAddress.Any results in using *all* addresses and
interfaces.

 

[paal.andreassen]

I have a problem. I have two instances of a client-server application
running on two different machines A and B.

A has a listening service, that listens for connections from B
B has a listening service, that listens for connections from A

The problem is what IP to bind the listening service to. I can find
all local ip-addresses this way: [...]
But how on earth do I know which one to bind and listen to? There's a
mix of IPv4 and IPv6 addresses, virtual vmware addresses, one from the
wireless wifi card and one from the ethernet cable.

Yup. Knowing which one to bind to depends on the network you want to listen on.
If A is publishing its IP to B, then it really doesn't matter what B publishes
on does it? You could just create your IPEndPoint using IPAddress.Any as the
IPAdress argument to just grab whatever the system thinks is best, i.e.:

Int32 port = 10101;
IPEndPoint myEndPoint = new IPEndPoint(IPAddress.Any, port);

Chris.

On the server-side I can have the service bind to IPAddress.Any ok,
but the client still needs to know the "correct" IP address for the
server. Iterating thought hostEntry.AddressList returns several
addresses, how do I know which one to use? I'd really like to automate
this and not ask the user "which of the following IP addresses is the
right one" if you follow.

Like I said, I put the IP address in a SQL database which is shared
between the clients. The client is then supposed to use this IP to
access the service directly. But on a given machine AddressList might
return several different IP addresses, but only one is actually
enabling access from outside the computer. The problem is to identify
which one I should but in the database.

Example, on a give computer I get two different IP Addressen in the
hostEntry.AddressList:

0: 10.70.0.125 InterNetwork
1: 10.0.0.14 InterNetwork

In this case I know that entry 0 is a VPN tunnel to another network
and is not interesting. It's 10.0.0.14 that my service is accessible
from the other clients in the network.

Can I detect which of these are used with the default gateway? Or is
that a dead end?

 

[Chris Shepherd]

On the server-side I can have the service bind to IPAddress.Any ok,
but the client still needs to know the "correct" IP address for the
server. Iterating thought hostEntry.AddressList returns several
addresses, how do I know which one to use? I'd really like to automate
this and not ask the user "which of the following IP addresses is the
right one" if you follow.

The difficulty lies in routing tables and knowing how the server can connect to
the client. Why you are publishing the IP of the server to an SQL database is
beyond me because it sounds like you're trying to reinvent DNS. A simple DNS
entry would completely solve this problem, IMO, as you could just see what IP
that hostname resolved to, and have that stored in the application's configuration.

If there were a "proper" solution, I'd think it's the one that involves using
the technologies standard to 95% of networks out there.


Chris.

 

[Chris Shepherd]

On client-side, IPAddress.Any lets the system choose one (and only one). On
server side, though, IPAddress.Any results in using *all* addresses and
interfaces.

I misunderstood the OP, and was operating under the theory that it was the
client that was needing to publish it's IP to the server, not the other way around.


Chris.