Thanks for the info.
Yes I'm using ASM multicast. (as in IP_ADD_MEMBERSHIP)
On Mon, 2 Nov 2009 09:32:43 -0600, "AliR" <AliR@online.nospam> wrote:
I have a client that has a computer with two NICs in it. Each NIC is
connected to a different network. It appears that when my windows service
application starts and creates a receiving multicast socket it binds to
of the NICs, and it happens to be the wrong one. (We verified this by
disabling the unrelated networks NIC and everything works fine at that
My understanding of Bind was that if you passed NULL for the IP address
it will bind itself to all the network interfaces!
The network address, a dotted number such as "22.214.171.124". Passing the
string for this parameter indicates the CAsyncSocket instance should
for client activity on all network interfaces.
Is that not true? Did I misunderstand something?
I'm guessing that I will have to ask the user of computers with multiple
for a specific IP to bind to. Is this the correct approach?
Use netstat -an to determine where your application's port is bound or
use TCPView from www.sysinternals.com for a Windows version of it that
will also list the process name and PID for easier identification.
Are you sure your intent is "multicast" or do you mean your intent is
to bind to address 0.0.0.0 (the _broadcast_ address) and a particular
port for TCP listen? The term multicast has particular meaning in
TCP/IP and it's difficult to tell if you are using it correctly in
When an application is not bound to a particular NIC, the routing
metrics prevail and packets emitted from a port will be transmitted
from the NIC with the lower metric. Use route print to determine if
the NIC your application prefers is the one with the lower metric.
Which NIC gets the lower metric depends on the order the NIC are bound
to the TCP/IP stack or to the interface speed.
Your solution to allow the user to bind the application to a
particular host address is probably preferable to messing with the
If binding to 0.0.0.0:port in TCP/IP as a listening service there
shouldn't be much of a problem since an incoming TCP SYN frame to that
port will be passed to your service and the routing becomes irrelevant
for the established connection. If your application is truly
multicasting from that port it's another matter.