why does winsock allow multiple UDP sockets bound to same IP/port?

C/C++ VCC programmer here. I think winsock should prevent me from doing the below in a 2nd running instance of my uDP server application, but maybe I'm forgetting something. basically, I create a socket...

Code:

---

SOCKET *pSock = socket(  AF_INET,  SOCK_DGRAM,  IPPROTO_UDP);

---

Of course I make sure the result is != INVALID_SOCKET;

Now although it isn't mandatory, I'm on a multi homed machine, so I specifically bind the socket to the IP I want to use, and a specific port I want to listen on. So...

Code:

---

struct sockaddr_in sock_adr;
char szMyIP[20] = { "192.168.0.60" }; // Just for example.
unsigned short port_num = 12001;      // ditto

sock_adr.sin_family = AF_INET; 
sock_adr.sin_addr.S_un.S_addr = inet_addr(szMyIP ); 
sock_adr.sin_port = htons( port_num); // port to listen on

---

before I bind, I do a sock option to allow broadcast messages on UDP, because I need to do that sometimes.

Code:

---

BOOL bSockOpt = true; 
setsockopt(*pSock0, SOL_SOCKET, SO_BROADCAST, (char *)(&bSockOpt), sizeof(BOOL));

---

And then i do the bind...

Code:

---

if (bind(*pSock, (struct sockaddr *)(&sock_adr), sizeof(struct sockaddr_in)) == SOCKET_ERROR)
    {
      errStat = WSAGetLastError();
      // ... take evassive action
    }

---

OK... now I understand that UDP is a connectionless interface. But it seems to me that if I specifically bind to a specific local IP and non zero port number, a second instance of the application should fail that bind and return a socket error when I try. It doesn't make sense for the system to allow two identically "named" sockets (meaning the same type, home IP, and IP port). When I did something similar in JAVA (using JAVA nio), a second app would fail unless I specified '0' for the port number, to let sockets choose its own unused port.

This is not so good. Amazingly both identical sockets in the two app instances work fine, which will confuse my UDP client apps. ("hey... why are you trying to request operation 'x', when YOU just requested that operation?").

I guess I could find a way to see if the my application is already running and either block a second instance or warn that certain operations will be blocked. But isn't there a way I could inquire of winsock before I bind my socket, to see inf there are any others already bound to the same IP and port, and block it myself?

Quote:

---

Originally Posted by Randy C

C/C++ VCC programmer here. I think winsock should prevent me from doing the below in a 2nd running instance of my uDP server application, but maybe I'm forgetting something. basically, I create a socket...

Code:

---

SOCKET *pSock = socket(  AF_INET,  SOCK_DGRAM,  IPPROTO_UDP);

---

---

AFAIK socket function returns the SOCKET instance, not the pointer to it.

Your right... my bad... I left out a step for the sake of a brief post. What i should have quoted was more like...

Code:

---

SOCKET sock0;
SOCKET *pSock0 = &sock0
// THEN...
*pSock = socket(  AF_INET,  SOCK_DGRAM,  IPPROTO_UDP);

---

I *AM* doing it correctly, or the bind would have failed, and I've already proven it works. But I'm still very confused as to why winsock allows it.

Quote:

---

Originally Posted by Randy C

before I bind, I do a sock option to allow broadcast messages on UDP, because I need to do that sometimes.

Code:

---

BOOL bSockOpt = true; 
setsockopt(*pSock0, SOL_SOCKET, SO_BROADCAST, (char *)(&bSockOpt), sizeof(BOOL));

---

And then i do the bind...

---

But why do you call setsockopt before rather than after the bind?

Quote:

---

Originally Posted by VictorN

But why do you call setsockopt before rather than after the bind?

---

Well I was doing it after, but I saw this in the MSDN...

Quote:

---

Note If the setsockopt function is called before the bind function, TCP/IP options will not be checked with TCP/IP until the bind occurs. In this case, the setsockopt function call will always succeed, but the bind function call can fail because of an early setsockopt failing.

Note If a socket is opened, a setsockopt call is made, and then a sendto call is made, Windows Sockets performs an implicit bind function call.

---

Now none of this really addresses my issue, but from the above I thought MAYBE doing my setsockopt()s first MIGHT make my bind more likely to fail is it found a conflict (multiple processes binding a socket to the same port and IP).

I'm starting to think with UDP, it may be a matter of opinion whether or not multiple processes binding a socket to the same IP/port is a problem or not. But it would be nice if I could at least find a way to inquire to winsock and discover for myself if another process has bound a UDP socket to a given IP and port already, even if its not technically an error. :-)