Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

CtrlAltDel

Multi-Threaded Client???

This topic is 5535 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
"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.



Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
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.

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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
<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>

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Right; by asynchronous sockets I meant sockets that notify the program of events by sending a message through the window procedure.

RapscallionGL - arriving soon.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!