I''ve created about 80% of my network stack and messaging engine so far but just read a tutorial over at flipcode that suggested that Multithreading the client netcode is a good idea. So far I''ve used threading on the server along with recvfrom for responsive event driven code. The second thread is timed to echo a compressed collection of all packets recieved in the last X seconds. On the client however we have a persistant loop that can be used to poll the buffer so I havent implemented threading. My thoughts were : "Why thread the client when we can''t process the data any more quickly anyway as we have to wait for the rendering to complete before using the new data(from the network)." Can anyone think of a good reason to thread the client? Thanks gimp

If you multithread the client, you can stick all (well, most anyway) of the network code in a separate thread and use blocking I/O. This takes advantage of the natural wait cycles that occur in network I/O. In turn it makes the code cleaner (always a plus) and could possibly, by freeing control constructs and eliminating polling, increase the amount of processing time alotted to rendering or other game processing.

Ahhh I see, my thinking was that after rendering was complete I would start the nex loop, check the mailbox and process the new data... I wasn''t considering the possibility that there might now be and data in the buffer...

good call...thanks