Sign in to follow this  

Multiple connected UDP sockets listening on the same port...

This topic is 4205 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 pair I 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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

This topic is 4205 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this