Question on Server - Client theory
Author
Hey,
I have been wondering for some time how the main loop of a server would look and how the client''s main loop would look.
What I mean is, how would it accept multiple connections, process the game state, and recieve client updates without using threads/processes of some sort?
What I plan on applying this to, is a simple game that accept manu simultaneous clients, recieve client updates, and send world state updates to the client.
Thankyou,
Michael Bartman
Within a single thread? select().
They just do polling and check for file desriptors open for reading (or writing).
Just do a search on google for "select()" or "BSD Sockets". It''s a pretty well covered topic.
If you want to play around, Perl and Python support select() as well. The Medusa package written in python is an asynchronous server/client module that uses select().
Interim
They just do polling and check for file desriptors open for reading (or writing).
Just do a search on google for "select()" or "BSD Sockets". It''s a pretty well covered topic.
If you want to play around, Perl and Python support select() as well. The Medusa package written in python is an asynchronous server/client module that uses select().
Interim
Keep it simple - stay away from threads. Using sockets you can do asynchronous reading/writing/checking for incoming and outgoing data. Write your code such that you call your net_process() function once per frame and let it take care of reading input, sending out batched output and other connection related details.
Interesting. I do not think that you could solve this problem given multiple simultaneous sockets without at least one worker thread to handle the incoming data. For example, you need a loop to check for incoming data. If you use them primary thread, then there is no way to process incoming data without ignore new updates.
Kuphryn
Kuphryn
quote:Original post by kuphryn Interesting. I do not think that you could solve this problem given multiple simultaneous sockets without at least one worker thread to handle the incoming data. For example, you need a loop to check for incoming data. If you use them primary thread, then there is no way to process incoming data without ignore new updates.
Incoming data is buffered, so you aren''t going to lose anything between calls to recv() assuming you aren''t overflowing your buffers. Old text MUDs use many sockets (TCP) within a single thread/single process architecture and it works great considering they handle all the players, and the entire world on a single system. Single-threaded asynchronous delivery and receipt is probably the way to go in most cases. You can timeout your network functions in such a way to maintain high level of control over the processing time dedicated to networking.
Author
Hey,
My original post contained a lot more content, and intelligent questions, but alas GDNet decided to give me an error and erase my post. So here is my best attempt to reconstruct my previous post:
I plan on writing a mud like game, using my existing, although incomplete, C++ game engine.
After the text client is completely flushed out, I will begin writing a graphical client. That should not be too difficult because the client is just a world renderer essentially. As long as I use the same packet structure as the previous client, everything should go smooth.
I have notice that SMAUG based mud''s have a worker thread as well as a primary thread. If I were to follow a similar setup, would my worker thread manage world updates and the primary thread manage connections?
I appreciate and highly value your input as users of GDNet and as game developers.
Thankyou,
Michael Bartman
My original post contained a lot more content, and intelligent questions, but alas GDNet decided to give me an error and erase my post. So here is my best attempt to reconstruct my previous post:
I plan on writing a mud like game, using my existing, although incomplete, C++ game engine.
After the text client is completely flushed out, I will begin writing a graphical client. That should not be too difficult because the client is just a world renderer essentially. As long as I use the same packet structure as the previous client, everything should go smooth.
I have notice that SMAUG based mud''s have a worker thread as well as a primary thread. If I were to follow a similar setup, would my worker thread manage world updates and the primary thread manage connections?
I appreciate and highly value your input as users of GDNet and as game developers.
Thankyou,
Michael Bartman
As I have learned many times, ALWAYS copy your message content before posting to gamedev.
Good luck with your game!
Good luck with your game!
Author
I am starting to do that from now on 
Thank''s jermz!
Later all and thanks again,
ps in trying to post this message, I have encountered the same error 3 times as of writing this...
Michael Bartman
Thank''s jermz!
Later all and thanks again,
ps in trying to post this message, I have encountered the same error 3 times as of writing this...
Michael Bartman
Author
Hmmm,
Was I correct when I made the assumption about what the primary and worker threads would do?
I''ll restate what I had posted before so that you don''t have to read through it:
If I were to follow the Primary and Worker thread idea that many muds currently do, what be the purpose of each thread be? Would the primary manage connections and the worker update the game state?
Thanks,
Michael Bartman
Was I correct when I made the assumption about what the primary and worker threads would do?
I''ll restate what I had posted before so that you don''t have to read through it:
If I were to follow the Primary and Worker thread idea that many muds currently do, what be the purpose of each thread be? Would the primary manage connections and the worker update the game state?
Thanks,
Michael Bartman
Author
Ok,
I have looked over the Smaug MUD Codebase a little more in depth, and here is what I have found in case others are interested:
For Win32 hosts, it uses 2 threads; a mainthread and a workerthread.
For *nix hosts, it uses a large loop for everything.
The function main() sets up all of the neccesary things, sockets etc and then starts a function called game_loop().
Inside of game_loop(), the loop starts out listening for connections and then if there are any, it accepts them. If not, then it proceeds to process world updates via update_handler.
Looking over existing, solid massive multiplayer capable network code has made the general idea much clearer to me.
For others interested, visit www.smaug.org and download smaug.
Later,
Michael Bartman
I have looked over the Smaug MUD Codebase a little more in depth, and here is what I have found in case others are interested:
For Win32 hosts, it uses 2 threads; a mainthread and a workerthread.
For *nix hosts, it uses a large loop for everything.
The function main() sets up all of the neccesary things, sockets etc and then starts a function called game_loop().
Inside of game_loop(), the loop starts out listening for connections and then if there are any, it accepts them. If not, then it proceeds to process world updates via update_handler.
Looking over existing, solid massive multiplayer capable network code has made the general idea much clearer to me.
For others interested, visit www.smaug.org and download smaug.
Later,
Michael Bartman
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement