Seperate TCP connections for each user, and using that incredibly terrible Select() statement, worked fine for a few players at a time. Trying to get ready to expand a bit though, so was wondering what are the protocols/methods that are the ones-to-use as player counts increase [50 players.. 100... 5000... as player count gets large to huge]. TCP: Cycling through the 'select' statement each game step, which will FOR SURE have something waiting to be processed if there are even 50 clients in it's list, seems sort of silly [why even call it if you know for certain it'll immediately return, with a list of sockets that have tons and tons of ready-to-reads]. At this point, when the chance of readable data gets to be a sure thing, is it better just to make the socket non-blocking, and let it return instantly if it fails to read? UDP: Seems like with UDP I can use one socket for several players, but as player counts increase, should the sockets be divided up? If so, should it be done with port number... connected udp...something else? Also, with sending outgoing traffic on udp with large numbers of clients, what sort of issues can i expect to rise up trying to send out large amounts of packets through a small number of sockets. Just seems like when the player count gets large, a lot of the conventional ways of doing things seem to break down. A lot of the articles I've read mention breaking the client base up into a number of threads, and using what is effectively the select statement on a smaller set, but it seems like even that would return right away, since there'll likely aways be data to read, somewhere. any advice would be great.... looks like a tough problem in general though.

UDP is the choice for performance, TCP is the choice for guaranteed packets arrival and enviroments where packet loss is an issue.

theTroll

TCP: If you have a high action game, then you can skip the select(), and just cycle all the sockets using asynchronous reads. If you think only 1 in 10 or less will have traffic, using select() is probably a win. If you want to scale to 5,000 on Windows, you have to use I/O Completion Ports for your I/O.

UDP: Use a single socket, but make sure the buffer is big enough that you don't lose packets while processing an unusually large packet. If your server tick rate is 30 Hz, I would have at least 100 ms (three ticks) of buffer space in the UDP input buffer. For example, if you're getting 1 kB/s per client of input, and 5,000 clients, you need a 500 kB buffer.