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:
Hi guys,
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
one
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
point).
My understanding of Bind was that if you passed NULL for the IP address
then
it will bind itself to all the network interfaces!
From CAsyncSocket::Bind
lpszSocketAddress
The network address, a dotted number such as "128.56.22.8". Passing the
NULL
string for this parameter indicates the CAsyncSocket instance should
listen
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
IPs
for a specific IP to bind to. Is this the correct approach?
Thanks
AliR.
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
this context.
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.
http://support.microsoft.com/kb/894564
Your solution to allow the user to bind the application to a
particular host address is probably preferable to messing with the
routing metrics.
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.