Multi-Threaded Client???
Author
I know its best to create a multi-threaded server(well most of the time), but what about when it comes to clients? The client is not always going to know when to receive messages from the server, so...what does it do? Should I create a thread that deals with recieving?
"I know its best to create a multi-threaded server"
You are wrong. Most of the time it isn''t, too much overhead.
If you''re going to target windows platforms, you''d better choose asynchronous sockets (for both client and server). A message pops up in the win32 queue when there''s something coming. Very useful and kinda easy to put it together.
You are wrong. Most of the time it isn''t, too much overhead.
If you''re going to target windows platforms, you''d better choose asynchronous sockets (for both client and server). A message pops up in the win32 queue when there''s something coming. Very useful and kinda easy to put it together.
quote:Original post by Cahaan
If you''re going to target windows platforms, you''d better choose asynchronous sockets (for both client and server). A message pops up in the win32 queue when there''s something coming. Very useful and kinda easy to put it together.
But is the windows message queue not slow ? Why not just poll the UDP socket each frame ?
For high-traffic servers (serving over ~1000 users, depending on machine setup, operating system, and other factors), it''s best not to use asynchronous sockets and switch over to IOCP due to efficiency issues. However, asynchronous sockets are just as efficient as other schemes for servers that won''t see a relatively high volume of traffic.
The basic premise of async sockets is that the window is notified only when an event occurs pertaining to the socket; the overhead is mostly the GetMessage() and DispatchMessage() calls. What you''re really comparing is the efficiency of retrieving a message off the queue and dispatching after a varying number of frames (there probably won''t be events waiting *every* frame) versus checking the state of a UDP socket *every* frame (when, again, there probably won''t be events waiting every frame). In that case, asynchronous sockets may be the better solution because the program only acts in reaction to a real event rather than acting when no events have occurred.
RapscallionGL - arriving soon.
quote:Original post by granat
But is the windows message queue not slow ? Why not just poll the UDP socket each frame ?
The basic premise of async sockets is that the window is notified only when an event occurs pertaining to the socket; the overhead is mostly the GetMessage() and DispatchMessage() calls. What you''re really comparing is the efficiency of retrieving a message off the queue and dispatching after a varying number of frames (there probably won''t be events waiting *every* frame) versus checking the state of a UDP socket *every* frame (when, again, there probably won''t be events waiting every frame). In that case, asynchronous sockets may be the better solution because the program only acts in reaction to a real event rather than acting when no events have occurred.
RapscallionGL - arriving soon.
<p>
I''m just now completing development on the network layer for a muliplayer game I''m developing as an assigment for class..
</p>
<p>
It supported TCP and UDP, where UDP is used for ''redundant'' messages, such as player movement, TCP was used for more important messages that can wait, but have to arrive, such as ingame chat && game syncronisation at startup...
</p>
<p>
Due to the very complex nature of the adventure game I was developing I had the server create threads for every client, to create some kind of peer to peer structure.
</p>
<p>
For every client there''s a TCP Thread, which would first check if there are messages pending on the socket and than add them to the message recv. buffer, then it would send message that where pending on the message send buffer. Same thing for UDP and for every client on the server.
</p>
<p>
While u could argue whether the UDP thread was absolutely necceserary, the TCP thread is, because TCP would not get out of send untill an acknowledge, this way all of your clients would need to wait for the slowest client, making any kind of timing (game speed on the server) almost impossible...
</p>
I''m just now completing development on the network layer for a muliplayer game I''m developing as an assigment for class..
</p>
<p>
It supported TCP and UDP, where UDP is used for ''redundant'' messages, such as player movement, TCP was used for more important messages that can wait, but have to arrive, such as ingame chat && game syncronisation at startup...
</p>
<p>
Due to the very complex nature of the adventure game I was developing I had the server create threads for every client, to create some kind of peer to peer structure.
</p>
<p>
For every client there''s a TCP Thread, which would first check if there are messages pending on the socket and than add them to the message recv. buffer, then it would send message that where pending on the message send buffer. Same thing for UDP and for every client on the server.
</p>
<p>
While u could argue whether the UDP thread was absolutely necceserary, the TCP thread is, because TCP would not get out of send untill an acknowledge, this way all of your clients would need to wait for the slowest client, making any kind of timing (game speed on the server) almost impossible...
</p>
The Winsock Programming FAQ
"Which I/O Strategy Should I Use?" (from that FAQ)
There are examples in the FAQ of a few different clients and servers, and links to other websites with more example programs.
Suffice it to say that for windows clients, the best strategy to use will almost certainly be Asynchronous Sockets. IIRC there are articles about using Asynchronous sockets right here on GameDev.
[Edit: Found the article:
"Programming with Asynchronous Sockets"]
John B
[edited by - JohnBSmall on April 19, 2003 9:38:51 AM]
"Which I/O Strategy Should I Use?" (from that FAQ)
There are examples in the FAQ of a few different clients and servers, and links to other websites with more example programs.
Suffice it to say that for windows clients, the best strategy to use will almost certainly be Asynchronous Sockets. IIRC there are articles about using Asynchronous sockets right here on GameDev.
[Edit: Found the article:
"Programming with Asynchronous Sockets"]
John B
[edited by - JohnBSmall on April 19, 2003 9:38:51 AM]
Author
Okay, thanks a lot for clearing things up...I''ll be sure to check out those links...
quote:Original post by johnnie2
For high-traffic servers (serving over ~1000 users, depending on machine setup, operating system, and other factors), it''s best not to use asynchronous sockets and switch over to IOCP due to efficiency issues. However, asynchronous sockets are just as efficient as other schemes for servers that won''t see a relatively high volume of traffic.
Sockets that use overlapped I/O and completion ports are still asynchronous sockets.
Right; by asynchronous sockets I meant sockets that notify the program of events by sending a message through the window procedure.
RapscallionGL - arriving soon.
RapscallionGL - arriving soon.
If you''re on the client, make your sockets non-blocking, and read them all each frame. There''s very little overhead in reading a nonblocking socket that has no data.
For servers, write a single thread, and have it select() over all sockets, reading from all the sockets that have data (they should still be non-blocking).
This is not only very efficient (both for client and server); it also ports very easily to UNIX.
Multi-threading is almost never worth it for something with as much inter-dependence as a game; the locking overhead will kill you.
For servers, write a single thread, and have it select() over all sockets, reading from all the sockets that have data (they should still be non-blocking).
This is not only very efficient (both for client and server); it also ports very easily to UNIX.
Multi-threading is almost never worth it for something with as much inter-dependence as a game; the locking overhead will kill you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
