Multi-Threaded Client???

"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.

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.

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.

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]

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.

quote:

---

Original post by 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.

---

i havent prged a mplyer game yet so i my not know what i''m talking about. but it would prb be better to have a seperate thread using blocking functions, so they wait until they get something and pipe it into whatever needs it. what locking overhead is there? if the critical section is tiny it should be better or the same as polling it.

quack, that''s nonsense.

What the AP suggested is: One thread that polls the socket directly.

What you suggested is: One thread that reads from the socket and posts into a queue. One thread that polls the queue directly.

You don''t gain _anything_ by doing what you suggested. In fact, your suggestion is worse in every way. It requires more resources, makes the code bigger introducing potential bugs and increases latency problems (because of scheduling between the two threads).

cu,
Prefect

Someone told me that select() was a bad API ever award. So which is the most common model of using asynchronous sockets for clients, WSAAsyncSelect()?
And if I create a thread to handle my own network messages, will it cost more overhead than windows messages? How about the approach? ( I used select() before ).

quote:

---

Original post by Prefect
quack, that's nonsense.

What the AP suggested is: One thread that polls the socket directly.

What you suggested is: One thread that reads from the socket and posts into a queue. One thread that polls the queue directly.

You don't gain _anything_ by doing what you suggested. In fact, your suggestion is worse in every way. It requires more resources, makes the code bigger introducing potential bugs and increases latency problems (because of scheduling between the two threads).

cu,
Prefect

---

i haven't programmed a mplayer game yet, just socket programing. I meant one thread reads the data and the main game loop checks a q. Not two threads. my idea is the same as AP but instead of an asynch read it does a blocking read, the thread doesn't really have anything else to do.
Well i guess my game when i make in mplayer is gona be tougher then i thought










[edited by - quack on April 22, 2003 11:40:38 AM]

[edited by - quack on April 22, 2003 11:46:18 AM]

What you suggest is still a program with _two_ threads, not one. The main loop runs in one of the threads (probably the original thread), while the blocking reads run in the second thread.

cu,
Prefect

Quack, you are adding another (redundant) layer of abstraction when its already in place. If you set your sockets to non-blocking, then the OS kernel has taken the place of your blocking thread for reading the socket and filling the "queue" (in this case the queue is actually your socket''s recv buffer). It doesn''t make much sense to have a thread dedicated to do that again. However, if the receiving thread actually takes some action, like parsing the incoming data and building a web page, then it makes sense.