Sign in to follow this  
blairhush

multiple udp sockets :O

Recommended Posts

right well im writing a chat server, at first there is one socket that listens for data from any host on port 9990, as soon as a client sends the SYN, the server creates a new socket for this client, and proceeds to send the SYN-ACK to it and recvfrom the ACK, but if i have two sockets... both recvfrom'ing and one accepts any address, and the other a specific address, how can i know which socket the data will be sent to :|

thanks.

Share this post


Link to post
Share on other sites
A UDP socket is identified by a (IP address, port) pair. Thus, the data will be sent to the socket with the matching port number.

Try not allocating an additional socket per client. There is no reason to, a single UDP port can serve many clients. It is generally considered one of the upsides of using UDP. Allocating additional sockets can cause (even more) problems with NAT.

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1306252375' post='4815164']
A UDP socket is identified by a (IP address, port) pair. Thus, the data will be sent to the socket with the matching port number.

Try not allocating an additional socket per client. There is no reason to, a single UDP port can serve many clients. It is generally considered one of the upsides of using UDP. Allocating additional sockets can cause (even more) problems with NAT.
[/quote]

i have potentially 5000 clients, so are you sure this is the best approach? or is keeping a list of the sockaddr_in structs for each client the best idea, then when data is recieved loop through that list to see who it came from?

Share this post


Link to post
Share on other sites
[quote name='blairhush' timestamp='1306256141' post='4815189']
[quote name='rip-off' timestamp='1306252375' post='4815164']
A UDP socket is identified by a (IP address, port) pair. Thus, the data will be sent to the socket with the matching port number.

Try not allocating an additional socket per client. There is no reason to, a single UDP port can serve many clients. It is generally considered one of the upsides of using UDP. Allocating additional sockets can cause (even more) problems with NAT.
[/quote]

i have potentially 5000 clients, so are you sure this is the best approach? or is keeping a list of the sockaddr_in structs for each client the best idea, then when data is recieved loop through that list to see who it came from?
[/quote]
No, it makes no difference. They still have the combination [SourceIP][SourcePort][DestIP][DestPort]. Since the DestIP and DestPort on your machine are always constant, you only need the first two values.

The number of clients is irrelevant, each has a unique header. Even when they are behind a NAT, the [SourceIP][SourcePort] pair will be unique for each connection to your server. Stored in a simple binary tree or otherwise sorted container it is trivial to look up one client in 5000. You'd need many millions of connections before the [SourceIP][SourcePort] pair becomes difficult to work with, and you'd have other processing bottlenecks long before you hit that limit.


The major compelling reason to use multiple ports is because you have a system with a completely separate and unrelated communications systems. For example, perhaps you are using a VoIP library with your game. The VoIP library may be written completely independent of your own networking system, it has implemented its own networking system. In that case, let the VoIP system use its own preferred port, separate from the network port your game uses.

Share this post


Link to post
Share on other sites
[quote name='blairhush' timestamp='1306256141' post='4815189']
i have potentially 5000 clients, so are you sure this is the best approach? or is keeping a list of the sockaddr_in structs for each client the best idea, then when data is recieved loop through that list to see who it came from?
[/quote]

Yes, you absolutely want to keep a single UDP socket. You may want to increase the size of the kernel receive buffer to cover, say, two net ticks' worth of data from all of the players, though.

When you receive on a UDP socket, you use recvfrom(), which returns the remote address (IP + port). Use this IP + port as a key into a hash table or map where you store the actual "user object" for that particular remote player. You probably want to also expire user objects that have not received a packet in some amount of time; say 10 seconds or so.

Share this post


Link to post
Share on other sites

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