How to hold account information!

I was thinking of using a map but! I know insertion into a map is pretty slow

Inserting and most every operation on std::map is O(log n). That's insanely fast. If you feel that you are doing millions of insertions and need something faster and don't care about order just use std::unordered_map which is a hash implementation with O(1) operations. What I'm saying is this is not something you should be worrying about speed-wise. These container operations are essentially free for the number of operations you'll probably be doing with them.

My main question comes from the Sessions that each player will have when connecting to the server so I can keep track of all their online states and sub information. I was thinking of using a map but! I know insertion into a map is pretty slow and map's so should I worry at this point? Or is there anyway to index the Sessions so I can access their information like a map based on port because I'm using UDP as my protocol. Or is it best just to do a list and go through them all which sounds pretty bad but not exactly sure at this point.

Using a map-like structure for the actual user is something you'd do in a dynamically typed language like Python, but probably not in a statically typed language like C++.

In a typical network server, you'd have one hash table from network identifier (socket for TCP, remote ip:port for UDP) to user object. The user object contains methods/fields for all the kinds of data you need to keep about a particular user in a particular session. This allows you to use static type checking for all the data you want to access about a user, which is one of the major benefits of C++. If you don't want to use static typing, use some language that's faster to develop in :-)

And, as always when it comes to performance: It's not a problem until you have a measurement that shows it's a problem. If you can't measure the problem, you can also not measure the possible solutions to determine whether the problem is gone or not.

Using a map-like structure for the actual user is something you'd do in a dynamically typed language like Python, but probably not in a statically typed language like C++.

In a typical network server, you'd have one hash table from network identifier (socket for TCP, remote ip:port for UDP) to user object. The user object contains methods/fields for all the kinds of data you need to keep about a particular user in a particular session. This allows you to use static type checking for all the data you want to access about a user, which is one of the major benefits of C++. If you don't want to use static typing, use some language that's faster to develop in :-)

And, as always when it comes to performance: It's not a problem until you have a measurement that shows it's a problem. If you can't measure the problem, you can also not measure the possible solutions to determine whether the problem is gone or not.

When i approached this problem i ended up with multiple representations of the same data.

So for example i had 3000 users, for quick access to a user i had an unordered_map which referenced their file descriptor (for TCP sockets) and a pointer to their information.
As these users could be referenced in groups, e.g. for chat events etc, i would then have seperate lists and vectors as neccessary which then also contained pointers to these same user objects.

As sometimes you will want to iterate the set quickly and other times you will just want random access to a single entity quickly, this is usually the best way to go in my experience.

Please note that most of my experience in networking is not with writing game servers but with writing highly scalable non-game tcp servers (irc daemons mainly) so with any advice i give... your mileage may vary.

Hey guys!
Sirisian:
Thank you for opening my eyes to that I had a misconception should have checked the complexity before judging it for speed lol Thank you!


hplus0603:
Actually had that in mind because it makes a lot of sense just to have an object that will house all important user data in a centralized object without having to do multiple calls around the code.
And yea your right I shouldn't worry so much about speed when that isn't the issue lol I think the missing code for the speed issues to arise is in order first!

braindigitalis:
Giving different gateways to access the same set of data sounds a lot better than just one access route! Thanks for the suggestions

I really just wanted feedback because I know this forum is full of guys who know the solutions to these minor hurtles.

-Frank N.-