   Multiple connected UDP sockets listening on the same port...
  I am working on the networking core for a game system and have run into a problem and I'm not quite sure why it is happening, I'm sure there is some subtlety in sockets that I'm not accounting for.I'm using UDP sockets and connecting them to peers (via connect).  I experience the following situation.  I know that there are alternatives to doing it this way, but at this point I want to know why this is happening.I create a socket (A) that is bound locally and calls recvfrom on INADDR_ANY:5000    I then receive a packet on socket A, I create a new socket (X), bind it to port HOSTIP:5000, connect it to the incoming unique ip/port pair    I then receive a packet on socket A, I create a new socket (Y), bind it to port HOSTIP:5000, connect it to the incoming unique ip/port pair    I then receive a packet on socket A, I create a new socket (Z), bind it to port HOSTIP:5000, connect it to the incoming unique ip/port pairI then call recv/send on the new sockets (X,Y,Z)Only one of the sockets gets data on it (lets say socket Y).The data socket Y gets is the 'correct' data meant for that socket, the data sent to the other sockets don't appear on socket X, Y, Z or even A.There are no errors on the sending side or recieving side, they just say 'no data available yet' (they are non blocking).  If I try to recvfrom on socket A, it also says there is no data available.  So my question is, why doesn't this work?  I thought that since X, Y, and Z were all connected to different peers that the incoming data from those peers would get handed to the correct socket.  Even Stevens (Unix Network Programming) implies this should work (Socket Pairs pg 52, and figure 2.14 pg 55).  Any ideas?Thanks for any insight.Rosco   
  You will not receive data on more than one socket for a specific port. Binding more than one socket to the same port is not expected to work.Because the "winning" socket is connected using connect(), it will filter out data received from other places.Using connect() with UDP sockets is pretty much never the right thing to do. Instead, use a single socket, and use recvfrom() to see who sent it, and sendto() to send data out. (That'll be NAT friendly, too). You can use a hash of IP address and port as the key to look up your known list of clients based on the recvfrom() address.   ;  I know UDP is a different beast, but this is how TCP works, right?  It has multiple sockets receiving on the same IP:Port combo.  Is this a TCP specific thing?Rosco   ;  Well, each accepting socket in TCP is bound to another remote IP:PORT pair. In TCP, a "connection" is identified by the full tuple of local IP, local port, remote IP, remote port. UDP is connectionless, so "connecting" sockets is usually not what you want to do, as it only imposes limitations on your local socket, not on the protocol itself.;  Thats unfortunate, I thought that by 'connecting' the UDP socket they would follow the same rules as TCP (using the 4 tuple of local:port remote:port) to determine the correct socket to receive data.  Thanks for you help, guess it is back to recvfrom.Rosco   