Tcp server for game
 

I'm currently creating an online poker game server and client for a university project and the server part and how it deals with connections is something I have been thrashing (bad joke) about with for a while.
The game is cross platform using:
for tcp: Berkeley sockets and winsock
for threads: pthreads and pthreads-win32

My first thoughts were that i could use a multi threaded server to deal with connections. ie the server opens a listening socket in a thread, listens for connections, accepts new connections and spawns a thread which deals with this connection. The problem with this design is its not scalable, ie 50 connections equals 50+ threads :( also theres alot of mutex's required for the queue's of messages which are very time consuming.

I am now thinking a poker table is contained within its own thread, yet each connection does not have its own thread. This cuts down on the number of threads required and therefore the amount of mutexs ( and condition mutex's) required. Instead the table thread uses the age old select() func to find the sockets where a message has come in or where a message may goto. This method also has its draw backs in that the select func has quite a bit of overhead ( fill the fd_sets check them and then deal with them ). Winsock has a maximum number of sockets which select can use, but a #define FD_SETSIZE ?? can override this; I can not find if bsd also has this restriction ( anybody know? ).

So I am thinking the second method here is much more scalable and the best of both worlds, anybody got any thoughts on this? If theres anymore info you think is needed before you can make a suggestion just ask, I didn't want to make this a massive post.

cheers.
<edit> I should add that I'm using c++ to code this and theses arn't the only designs I have come up with, but are the best of the bunch</edit>

#define FD_SETSIZE -- BEFORE the other include (winsock[2].h for example - i think thats right)

I think BSD Sockets has the limitation as well but from what I have seen the limitation may not be a limitation (I've seen screenshots of 100+ connections and know the user did not touch fd_setsize...

SELECT seems to be the best way and the overhead I don't believe is that much... poll() (unix) or signals is another method but windows might have a limitation on like 64 events on a single thread (not verified by me)

using signals on Unix might be a good approach there - not sure on windows (it's basically an event)....

my 2 cents... take it for what its worth =)