ok at the moment I am using two threads one to run the game in and the other to send/recv stuff over the net using UDP. I am using two STL queues to link the two threads together. At the moment the main loop in my network thread looks like this (sockets are non-blocking):
Is there any more efficant method to do this? As at the moment I am a bit worried that the network thread is taking up more CPU time than need checking for messages when there are non there. I have thought about maybe using two network threads one using a blocking socket to recv messages and another using non-blocking socket and a semaphore to send data only when there is data in the queue. Or would just putting something like Sleep() in the loop help prevent it hogging CPU cycles. Cheers, Convict@Large

That thread is most definitely eating cycles, forever looping and doing nothing. Better is your idea to use a single blocking socket for receiving. Sending could be a pain, it might be better if you implement a second thread but use something like a semaphore to synchronize when things are in the queue rather than having that thread poll your queue. It might even be better to put the sending socket into your main thread at the point of send and let the network queue the packets although I''m not too sure on this.

What platform is this application supposed run on? Win32?? Linux?

There are many platform specific techniques you can use that will speed things up greatly.

not sure if this will work, but you could have a flag in the while loop. When ever something is sent or received, the flag is set. At the end of the loop, if the flag isn''t set, Sleep for a couple of milliseconds. That will keep the cpu usage down.

What platform is this application supposed run on? Win32?? Linux?

There are many platform specific techniques you can use that will speed things up greatly.

For example, Completion Ports are the way to go if you’re using Win32.

quote:

---

Original post by eli_pulsifer
What platform is this application supposed run on? Win32?? Linux?

---

Sorry eli_pulsifer I did not mean to ignore you, I was at the cinema. The code is ment to run on Win32 and maybe linux (probably only the server-side code if anything) at a future date but that has yet to be set in stone.


Cheers,

Convict@Large

Why use threads? If your already working with non blocking sockets just check to see if any data has arrived \ needs to be sent and continue with the game...

I doubt checking the send \ recieve queue''s once a frame will burn too much CPU.

As for the server side I use the method suggested above of a small sleep command. Even Sleep(1) on my system shows up as 0% CPU used and that means it''s probably looping ~1000 times a second, much more than is needed to run a server...

Chris Brodie
http:\\fourth.flipcode.com

Using a seperate thread for network receiving at least is good for real-time games because you don''t have to wait for the current frame to complete to place your messages into the message queue (or whatever you''re using).

But,...

(Client Assumption)
When your sending a packet it''s due to some user action. You can send the packet as soon at the input action was taken. I don''t act on input any more often than I need to send so I have no issue with waiting on the end of a frame. The only case in which is no longer works well is when your FPS drops below 10 ) By that stage you wouldn''t be able to see much of a network lag anyway :>

(Server Assumption)
In my case server''s job is to act on a clients data. On my server I use a syncronised combined update every 100ms, so I can process all the inbound client data just before that. I''m in no rush to grab data as soon as it arrives as I won''t use it until a certain place in the main loop anyway.

I can see few advantages to threads for networking...(besides the coolness factor)

Chris Brodie
http:\\fourth.flipcode.com

(Client Assumption)

What about keepalives? do you bother? Depends of course on the type of game, a fast FPS might get away with just sending on input, but a slower paced game using UDP might need to send regular packets to prevent being dropped.

(Server Assumption)

But the faster you grab packets the less likely you are to lose packets due to the (probably quite) limited driver queues.

Then again, I''m not arguing necessarily for threads and it all hinges on what type of game you are making.