   MMO Network Design Question (Hopefully Intelligent)
  For a good scalable MMO server/client setup I have read that blocking sockets are generally not a way to go as they can often tie up the system for quite long time periods. I also read that using select() carries a good deal of overhead with it if I call it too often. I will be using UDP so I am assuming that clients will be sending requests to the server and they will queue up in whatever order they recieve in for me to process. I will have to check that quese from time to time to see if any requests have been sent correct? And since simply listening to a socket until something arrives will tie up the system indefinitely (unless using threads) then that cuts out that option. Then the problems with select() eating up clockcycles especially when used too often. If have read here about IO completion ports but can''t seem to find much information on them so I can''t attempt them as a solution as of yet.So the question, listen is a blocking call which means it holds the processor until it receives something to do. Would this be OK in a multi_threaded system? I know that threads on a single processor won''t give any speed increase but they will essentially stop blocking calls from effectively blocking correct? Other than that I still read that many people use select regardless of the overhead associated with it.I just want to get my facts straight and a design clear before I code anything.I have worked through the chat tutorials I can find and have read Multiplayer Game Programming and other programming books a few times but they really don''t give any indications on which methods are good for systems that hope to have large numbers of clients.Any good info on IOCP would be nice. Keep in mind that I would like to develope this to hold a large number of players per server with checks to allow for server spillover and rerouting in the event of overpopulation or server crash. The main emphasis right now are the methods to allow for high numbers.The amount and type of information will be tailored as the game develops so I am hoping to develope network code that will accept pretty much any kind of data. Tweaking of the data transfer rate and amoutn can occurr later if the project ever makes it that far. For now I''d just like to create a system that would allow a massive number of clients. For data transfer I assume I can somewhat stress test it by simulating many clients all sending the largest conceivable amount of data per request over a period of time. Generally the largest amount of data won''t be sent and primarily the data will be things like movement change requests and action requests. That will all be decided at a later point.Any pointers appreciated.Webby  
  Firstly.. UDP doesn''t have connection states... so there is no "listen".  Secondly, the prefered method of handling sockets is using non-blocking (asynchronous) sockets with windows messages (if you''re developing under windows).  This way, when an event happens on the socket (data arrives, etc) it sends a message to your windows procedure (WndPrc) and you can check what happened.  This makes it unecessary for you to worry about threads and blocking calls, etc.  The last paremeter sent to your WndPrc is the SOCKET id, so you know which socket the event happened on.UDP also isn''t reliable.. you can have dropped, damaged, and/or out of order packets received.  You will want to create a priority type system that you can flag which packets need an acknowledgement (so you can resend if the packet doesn''t arrive properly), and store a packet order #, so if something comes in out of order, you can either A.) ignore it or, B.) process it anyways because order didn''t matter.  I am writing my winsock class using TCP/IP, this way, I can write the functionality, and I KNOW it''s gaurrenteed to make it, this way I don''t have to worry about errors popping up in my game because of a stupid error in my winsock code.  I will fill in the udp later, and if it doesn''t work then, i know where the problem lies.  ;  Just wanted to mention a few more things...Be careful with multi-threading.  Say you have a thread per user, and all users need access to the same database.  You then have to worry about 2 users trying to access the same data at the same time, which can cause problems that are very difficult to track down .  ;  Thanks.  Hadn''t planned on a thread per user. I was thinking more along the lines of one thread handling the receiving end of messages, one handling the processing of any received messages and another handling the sending of messages. Not quite sure but does a non-threaded application take advantage of a multiprocessor machine? Doesn''t seem like it would.Clients on the other hand will most assuredly be non-threaded or single-threaded (whichever is correct) and will only have to send messages to one place and likewise recieve messages from that same place.The server on the other hand. If I use UDP which doesn''t use connections then that means I can get any number of packets from any number of clients all coming into the same socket.So I might recieve a packet from player 1 then the second packet from player 3 and the third from player 1 again. This is easy to understand as long as each packet includes some information on who sent it then no problem. Main issue for me to understand there is what if a packet gets broken up. Then the first thing the server will see if the beginning of a packet from player 1 and next the beginning of a packet from player 2 and then the middle of a packet from player 1. Certainly not necessarly in that order.Right now I an thinking that the program will have to allocate a buffer for every single player in the game. So when i get the partial packets from player 1 I store them into his buffer until his complete packet arrives and then i act on it correct? I guess this is handled with some sort of checksum that says PacketX is 32 bytes and it''s ID is 111 so now I just wait until I get 32 bytes worth of packet with ID 111 and then i know I have a complete packet?That can get nasty if I ID packets that way, or is this something that is handled on another level?The more I think about it the more it makes sense to allocate a buffer for every player and just route their packet pieces to that buffer. I am trying to design around the fact that no single packet will transfer in it''s complete form. If they do then go-me-go-me but otherwise the system will be stable.I realize the buffer will need to hold enough for at least 2 packets to take into account recieving all of one packet plus a little more.Guess I just need to keep reading and playing around with it.Thanks for the reply. Keep them coming Webby  ;  > Then the problems with select()> eating up clockcycles especially> when used too often. There is nothing wrong with select() nor with multithreading, if used properly.The issue with this API is when it is used for checking both read and write states of a socket _at_the_same_time ! You simply can''t force a thread to break out of select() when another thread has something to write. People usually put in a very small timeout value so not to delay writing, hence that thread spinning its wheel and eating CPU for nothing (and hence its bad reputation).Nothing prevents you from having a thread blocking on a select() for reading only, and another thread blocking for writing only, both using the same socket (*). The write thread can be made to block on a semaphore which is tied to the number of outstanding outgoing messages; it blocks when either there is no message to send or when the socket is not write-ready.-cb(*) Use Winsock 2.0 or above for this to work.  ;  OK maybe I''m just not quite to grips with some of the fundamentals.If my program is just one main loop that doesselect() to see if something is to be readselect() to see if something is to be writtenthen this is potentially a bad idea because the first select will potentially wait (until it''s allotted time has expired) before it releases control for the next select() to function. So if I give it a time parameter of 10 milliseconds then it should just do a blazingly fast peek to see if there is something to be read (or written) and if that is the case I can branch off to handle that code.Or I can put each in its own thread which is really only useful on multi processor machines.I can see the select() with a very small time amount being able to cope with a lot of clients if the overhead for the call to select() isn''t too great.  I''m just looking for the most efficient in regards to CPU cycles.If that is using multiple threads for different clear cut and unrelated procedures then that''s OK. If it''s easy enough to just call select() every time I want to see if I can read or write then even better. That approach would work for me for now to test systems on a small scale but my purpose for doing this is to divise the methods that will actually be used as the network module if the game goes any farther than that.Besides, if I apply for a job in this field then I think it would serve me better to be able to say I have experience with networking code for large numbers of users as once that''s done it''s very very easy to divise a system that handles only a handful of users.Webby  ;  > Or I can put each in its own threadThat was the idea; each thread will block waiting for a specific (and independent) event. The multi-threaded select() solution can be used when you have a limited number of connections (<100) as select() scales badly with a large number of sockets such as in a [TCP-based] web server. Assuming you are using UDP, the number of sockets to monitor is reduced to one (or two with a separate login port), thus making this approach scale more. The next step in scalability is the implementation of a thread pool using IOCP.> ... I have read that blocking sockets> are generally not a way to go as they> can often tie up the system for quite> long time periods.Also noteworthy, many of the documented I/O strategies date back to 1996 - 1998 when the fastest Intel CPU was clocked at 350 MHz and this information is often carried forward in time without the proper context. With the newer 2Ghz+ machines out there, the ratio between I/O speed and CPU speed is rapidly dinishing giving application developpers even more incentives to avoid I/O polling strategies and do more useful calculations (like AI, pathfinding, ...) with the main thread''s time slice.Make sure you read recent articles (2001-2003) with experimental data to back them up; better still, make some test apps that would simulate the traffic using your protocol with a few I/O strategies.-cb;  I''d highly recommend looking into I/O completion ports. IOCP is a TCP/IP solution that is very efficient. The DAoC emulator i''m working on has a network core built on top of IOCP. You can download the code to it at http://dol.xopion.com  