I’m developing multiplayer game and I have a server written on asp.net. Game users send requests to server to find an oponent and join some kind of battle. Battle request can have some parameters, but it also can possibly have none (and it’s estimated to be the most popular scenario), so sender should be connected to any of users that have already sent their requests and wait for connection.
Is storing all waiting requests in a thread-safe collection a good idea? It always will contain quite a few elements (because matches for battle are found very quickly), however, a lot of threads will try to access this collection at a time. And is it a good idea to create different collection for every N requests? What is the optimal size of N? Or maybe some other ideas? My key issues are finding matches quickly and without damaging server performance, even if number of current connections is very big.
UPD
It seems that I’ve described my issue not very clearly. All battle information – participating users, actions during battle, winner etc., is stored in database. What I need is to process requests to join the battle (request contains only sender id and battle filters, possibly). Generally, opponent will be found almost immediately so there’s no need to store request data (it should be removed after match is found, and all battle data will be stored in database), but, however, I must be ready to process great amount of requests at the same time.
Without going into criteria for matching players, you should not hold user session data in memory when writing web applications. Your web application can be occasionally recycled causing your to loose data.
As SLaks said, you should store this data in database and make selection from there. You should think about performance optimization from this base line, depending on user matching logic. Either select top n users, or create a query based on desired criteria.