Hi.
I have one question about a server implementation.
What is the best way to implement a game server?
Using Threads by client? or then Threads "by process"?
ie. Thread for command translation, Thread for incoming
connections, thread for others functions or one thread
for incomming connections and n Threads for client
control ?
thx
cya--
bit, n:
A unit of measure applied to color. Twenty-four-bit color
refers to expensive $3 color as opposed to the cheaper 25
cent, or two-bit, color that use to be available a few years ago.
Interesting question.
I started to code a simple GameServer last week and found it to be harder than I first thought due to the inability to assign threads different priorities in SDL.
It has an impact on the design of a server since you want some importand threads (like the server socket AND, most importantly, the gameloop renderer if the server machine is also a client) to run with higher priority than others. SDL forces you to minimize the number of threads running concurrently. Even more important is it to avoid doing inefficient things in threads such as polling a client socket for incoming packets. It means that the “thread by process”-approach is always to prefer over “threads by client”. (And by process I assume you mean a clientrequest.)
This could introduce a new problem however; the overhead of creating threads at run-time, which is best solved by using a threadpool. That would beautifully solve the need to limit the number of threads since a good written threadpool would have a queue to store messages that cannot be executed when all threads in the pool are in use.
A simple workaround to skip the threadpool would be to just ignore the overhead (which probably isn’t that high anyway). You still need a variable that holds the number of threads in use and a queue for storing excessive messages though.
This way the hosting game player only needs two constantly running threads, those of highest importans, plus a third that loops thru the vector of client sockets checking for messages at some appropriate rate. All server processing is done in temporary threads and destroyed when nolonger needed. This requires some synchronization between the temporary threads when sending packets to clients and when accessing the client sockets vector.
Is there a better solution?
…johan>
Hi.
I have one question about a server implementation.
What is the best way to implement a game server?
Using Threads by client? or then Threads “by process”?
ie. Thread for command translation, Thread for incoming
connections, thread for others functions or one thread
for incomming connections and n Threads for client
control ?
thx
cya
Interesting question.
I started to code a simple GameServer last week and found it to be harder
than I first thought due to the inability to assign threads different
priorities in SDL.
Sure... hehe, I too.. and the server that i wanna do, is a board game
server.. a "simple" server.. :)
It means that the “thread by process”-approach is always to prefer over
"threads by client". (And by process I assume you mean a clientrequest.)
Hmm.. ok.
This way the hosting game player only needs two constantly running threads,
those of highest importans, plus a third that loops thru the vector of
client sockets checking for messages at some appropriate rate. All server
processing is done in temporary threads and destroyed when nolonger needed.
This requires some synchronization between the temporary threads when
sending packets to clients and when accessing the client sockets vector.
2 threads? one for clientrequests and one for gameprocessing...
the 3rd thread i think that dont change much the server performance?
Is there a better solution?
I think that is... i will try to "update" my server to see results..
I said this cause, exist a Ultima Online free server (Penultima Online - POL)
and i contacted the author.. see his response:
"POL uses one thread per client - mostly to make it easier to handle I/O.
It also uses threads to handle scheduled task and script execution.
There's one thread that handles all script execution, one that handles
decay, and one that handles scheduled tasks - combat, for instance.
It's a pretty simple design. One unfortunate aspect is that it doesn't
facilitate use of multiple processors, but on the upside, there isn't
much complexity relating to data synchronization."
...?
…johan
thx for your colaboration..On Saturday 23 February 2002 16:53, you wrote:
Hi.
I have one question about a server implementation.
What is the best way to implement a game server?
Using Threads by client? or then Threads “by process”?
ie. Thread for command translation, Thread for incoming
connections, thread for others functions or one thread
for incomming connections and n Threads for client
control ?
thx
cya
–
Death has been proven to be 99% fatal in laboratory rats.