🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Controlling a large number of sockets
Author
I''ve been working on a networking library for a while now, and want to make sure that my design will work work well for a large number of clients (i.e. massively multiplayer).
Right now I have one thread controlling all the network connections. I''m using multiplexing to poll the sockets, one call to select for the listening socket, and one for each client socket (So I overcome any "select" socket limitations).
Now, would it be better to spawn off a thread for each client (or maybe one thread for 10 clients) and use a blocking socket, or will my design handle a large number of users without bogging down the system on the number of selects I call (101 selects for 100 clients).
Maybe I was overworried with too many threads being spawned. Just want to get some other people''s opinion.
Platform means everything. What platform are you talking about? select() with an array of sockets is a good way of handling things on *nix, but for windows, you''ll probably want to go with some form of overlapped I/O. IO Completion Ports if you''re looking at Windows NT/2K/XP only (i.e. server-side).
On Windows, some kind of asynchronous socket would be the best idea for managing lots of them. You don''t really want to be polling all the sockets over and over, and definitely not blocking on one.
100 polling threads is a performance concern.
Magmai Kai Holmlor
"Oh, like you''ve never written buggy code" - Lee
Magmai Kai Holmlor
"Oh, like you''ve never written buggy code" - Lee
101 selects for 100 clients is a concern!
Select should be called with all the client sockets lumped together so you can then go through the selection list and check for events on those sockets. The overhead of calling select() for each socket will be problematic. I will be honest -- I havn't written a game network layer but I have written one for a MUD and a multi-user chat system. Put the listening socket in position zero of the socket set array, and the rest of the clients after that, in the array, and just call select() on the whole lot of them. I don't think you need a seperate select for the listening socket, let alone for each client.
But the others are right - if you are making a windows server or client use asynchronous events and overlapped IO. Unless you are making it portable, but then it might make sense to have WindowsSocket and a UnixSocket classes and split the code off up higher with a common API to the socket wrappers.
Edited by - Sphet on February 11, 2002 1:49:31 PM
Select should be called with all the client sockets lumped together so you can then go through the selection list and check for events on those sockets. The overhead of calling select() for each socket will be problematic. I will be honest -- I havn't written a game network layer but I have written one for a MUD and a multi-user chat system. Put the listening socket in position zero of the socket set array, and the rest of the clients after that, in the array, and just call select() on the whole lot of them. I don't think you need a seperate select for the listening socket, let alone for each client.
But the others are right - if you are making a windows server or client use asynchronous events and overlapped IO. Unless you are making it portable, but then it might make sense to have WindowsSocket and a UnixSocket classes and split the code off up higher with a common API to the socket wrappers.
Edited by - Sphet on February 11, 2002 1:49:31 PM
Author
I thought it might be a little bit of an overkill to do 101 selects. I can redo my design to implement 1 select for listening, and 1 select for all the clients (or 1 for all sockets). As for asynchronous sockets, I''m trying to stay away from having one class for windows and another for unix. I especially want to make the socket class include all the socket message handling, and not for windows to send messages to the application through it''s messaging system, makes for cleaner code in my case.
The library I''m trying to make is supposed to sacrifice some speed in order for it to be portable and very easy to use. I tried the one thread per client design, and that ate up about 95% cpu, so that''s out. I think the multiplexing was the best design to incorporate all the requirements.
Basically the library will allow you to make any program networkable with minimal additions to the user''s code. I''ve tested it out as a web server, and I am making a demonstration MUD (to test a large client base), and probably adding network code to some simple game source I can find on the internet (don''t have time anymore to work on the games aspect).
Anyway, all the comments are appreciated.
The library I''m trying to make is supposed to sacrifice some speed in order for it to be portable and very easy to use. I tried the one thread per client design, and that ate up about 95% cpu, so that''s out. I think the multiplexing was the best design to incorporate all the requirements.
Basically the library will allow you to make any program networkable with minimal additions to the user''s code. I''ve tested it out as a web server, and I am making a demonstration MUD (to test a large client base), and probably adding network code to some simple game source I can find on the internet (don''t have time anymore to work on the games aspect).
Anyway, all the comments are appreciated.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
