Use an associative container (a hash table or a map) to associate the name with the user identifier. Of course, you have to ask yourself whether this is really important, or if your precious time would not be better spent somewhere else (such as compressing position-change packets).

Quote:Original post by Khao
Doesn't it throws an error when you try to write to a socket that closed unexpectedly?

To the server, there is no difference between a dead connection (the computer on the other side is permanently unavailable) and a slow connection (the computer on the other side has not received the data yet). Servers usually implement a timeout system: before a certain duration, connections are considered slow, and beyond that duration they are considered dead. That duration, however, means that a player can attempt to reconnect even though his previous socket is not dead yet.

Quote:Of course, I'm not completely against restructuring my server, but I think it would create too many lists and maps. Socket -> User, UID -> User. For example if I need to send a chat command to all users logged into a lobby it would look like Lobby -> UIDs -> User -> Socket.

Where is the problem in that? You greatly overestimate the performance hit of following a few references (especially since the bottleneck will be the actual sending of the data, and not the reference following).

Quote:I think for me it is a very effective way to use sockets representing users, since when I see that the socket x has data to read from, userList[x] gives me the corresponding user. It seems to me that this also makes it a lot faster to find socket descriptors to write to, when I store a list of socket IDs in a game and I need to propagate a chat command for example. I only write to each ID in the list.

Effective in what sense? As far as elementary computer performace goes, there is no serious advantage to doing userList[x] instead of userList[playerid[x]], because the memory access time is so slow that it's dwarfed by all the other processing you do. In fact, making the cache locality better on the userList (by clustering identifiers close together instead of spreading them along socket numbers) you might actually get a performance gain by adding that level of indirection.

As far as object manipulation goes, you're violating the single responsibility principle: for instance, as outlined before, this completely prevents manipulation of offline players.

Quote:Of course I also take time to optimize packages being sent to be as compressed as I can, since it is a crucial point in a server.

My question wan't related to the 'of course I also' answer. I know you will do anything you can to optimize your game. What I was questioning is whether you actually enjoy spending a few days writing an optimization that result in no measurable performance gain. Beyond that, how you schedule your development time between things that matter and things that don't is your own personal choice.

You want a hash table. When you need to map ID -> object, without there being an obvious benefit in having an ordered collection, you always want a hash table. Unless you can use the ID as a direct index into a table, but that's often troublesome when objects go away.

Regarding delivering whispers (or whatnot), typically the ID table will map from ID to user object, and the user object will have an interface for "receive chat message" -- what that does, is up to the interface implementation, and may vary. For example, some users may have "ignore" or "filter" turned on, which means that the message will not be immediately sent on a socket (and may even be dropped on the floor, metaphorically speaking).

There is no important difference in memory usage between a map and a hash table in general. A map requires child pointers for nodes and storing the R/B state; a hash table requires the top-level pointers, list pointers and the hash code. They typically balance out. The only difference you should worry about is the trade-off of O(lg n) vs O(1) and sorted vs not.