   associating a packet with a particular user
  I'm writing a UDP server in C++ and I need a way to associate each packet with a particular user.I know recvfrom fills out a sockaddr struct for me (actually a sockaddr_in6 struct so I can deal with IPv6 addresses when they become commonplace), so I was thinking I should use a hash_map of the IP address and port (18 bytes) to look up which client sent it. If this is the case, what would be a good hash function to use? I'm not sure at all about the potential distribution of these addresses. Also, it would be preferable that the hash function doesn't suck for IPv4 addresses that are converted to IPv6 addresses (or maybe I should have two separate hash functions, one for IPv6 addresses and one for mapped IPv4 addresses (80 0 bits, 16 1 bits, 32 bits of IPv4 data)?).I was also thinking I could include a few bytes identifying the client in each packet, but this would (a) "waste" space on each and every packet and (b) be easily spoofable, so I'd have to check the address and port as well.Really I'm just looking for advice on what is a good, well-tested (or at least actually used by someone with more experience than me) method of linking a packet to a user. Once I get that down I can build off of that with authentication, actually sending data, etc etc.EDIT: Oh hell, I just read a random internet page that says the Windows XP version of IPv6 can't do the mapping of IPv4 addresses. Is that true?   
  I'll also point you to this.Personally, I use a single byte identifier, assigned by the game host, to each clients. It's only one byte (or two, or some variable bit length encoding...).As for spoofing, I rely on the packet encryption. Using a unique identifier takes the pain away. If you want to use address mapping, why not using your own internal address representation, that converts IPV4, IPV6, or whatever format, and also be usable / convertible as a hashmap key.   ;  Hmm so the IP address and port combination aren't reliable in the first place, since they might change randomly for a given client... I did know that could happen theoretically, but I've never noticed it screwing up my connection for any other programs, so I didn't account for that in my thinking.Really the address mapping thing only matters because I thought it would be a good way to identify a client reliably. If not then I don't care about it at this point.So is including a few bytes of identification info and maybe a few more bytes of anti-spoofing magic standard practice then? I'd like to not add too much extra size to every packet but if that works for everyone else I'm game.   ;  As far as I've seen, it's always been the solution. Quake3 changed from address mapping to using 2-byte identifiers as explained above, and I've always used, and seen used ids to identify clients. But you need some sort of handshake to let the client know what is his id and the host id, and so on).BTW, that problem with changing addresses seems pretty moot. You'd get a new IP when you re-connect with your ISP or when the DHCP's hand is forced, and then you'd loose your game session anyway. I'd like to know real-world experience with that problem (routers randomly re-assigning ports, ISP changing your IP during normal use, DHCP mucking about ...), since I haven't experienced it myself.   ;  If I don't need anything fancier, I often use the Phong hash. It's fast to compute, and gives a good distribution on almost all kinds of data.I kind-of like the hash to identify the user, without putting the ID up front. Others like the ID, and then verify the IP address matches the ID (to avoid impersonation). Which you end up choosing is really up to you.   ;  When I was at my last company we had load balancing and any communication over the internet could go over any one of our connections. This made sessions really hard to keep, for example I would have to login three times to my webmail for it to work. From the games I played there in my free time I notice world of warcraft didn't care about this but age of conan did. In reality this setup isn't normal especially for a home user, I wouldn't even deal with it.   ;  Thanks for all your input so far!Quote:Original post by hplus0603I kind-of like the hash to identify the user, without putting the ID up front.Why only "kind-of"? I would like to go this way myself, but I'm concerned about the IP address thing (which would also screw up the ID plus IP verification scheme). How would you deal with that?If I do go with the ID in each packet, but don't want to encrypt every packet and can't rely on the IP/port combination as verification, are there any other good methods of authenticating the packet came from the original client?   ;  Most load balancers are smart enough to not change the externally visible IP for each session. Perhaps the load balancer that Seoushi talked about was not smart enough. I don't generally care about that case, because it hasn't been a problem I've seen.At work, we also have a mode where we allow all traffic for a single session to get tunneled through a persistent TCP connection (which could use SSL, etc). This would remove that problem entirely, at the cost of having to run everything over TCP.