ID: Q156317
The information in this article applies to:
A UDP application that uses the bind() Winsock API to restrict incoming traffic to a particular interface will continue to receive broadcast messages directed to the subnet for that interface.
On most UNIX systems, it is possible for an application using UDP to filter out broadcasts that it would normally receive. This is accomplished by binding to a network interface explicitly instead of specifying INADDR_ANY.
The following code segment illustrates this operation:
{
struct sockaddr_in local;
local.port = htons(5001); // select some port
local.sin_family = AF_INET;
local.sin_addr.s_addr = INADDR_ANY;
bind(sockUDP, (struct sockaddr *)&local, sizeof(local) );
/* start doing recvfrom()s here */
}
If another application were to issue a broadcast datagram on the same
network/subnet, port 5001, the above socket would also receive this
datagram.
On the other hand, a UNIX-based sockets application would avoid receiving broadcasts by using a network interface address instead of INADDR_ANY. For example:
local.sin_addr.s_addr = inet_addr("11.1.1.1");
assuming 11.1.1.1 is a local network interface on the same host. These
applications, therefore, do not expect to see broadcasts unless they bind
to INADDR_ANY.
This is not the expected behavior on Windows NT and Windows 95. On these platforms, an application using UDP datagrams for communication will continue to receive broadcasts aimed at its network, whether or not it binds to INADDR_ANY.
Note that an application that binds to a specific interface will not receive datagrams, broadcast or otherwise, that are directed to another interface and its corresponding network/subnet.
This behavior is by design.
Additional query words:
Keywords : kbnetwork kbtshoot kbAPI kbNTOS351 kbNTOS400 kbSDKPlatform kbWinsock kbGrpNet
Issue type : kbinfo
Last Reviewed: August 6, 1998