No multithreading in the netcode?
by Matthew Shapiro · in Torque Game Engine · 06/21/2002 (11:26 am) · 2 replies
Ok i've recently downloaded torque again to look at the source code. I noticed that there are multithreading features in the engine, however Tim informed me that it was for the schedule. Now granted I havne't looked at the code in that much detail but It seems very odd to me that they didn't use multithreading for the network code, at least on client side. The way I understand it, if the main network code is multithreaded, the lag isn't partially based on how long it takes to render the scene. Now I don't know if the schedule takes care of this or not, but it makes since why multithreading the netcode helps with lag, as if the frame takes 40ms to render than thats 40ms more before the incoming traffic will be touched, thus increasing the ping. dunno just somenting i was wondering...
--KallDrexx
--KallDrexx
#2
07/03/2002 (8:02 am)
Multithreading really isn't worth it for the most part. The overhead with switching threads is significant, and most people only have one processor. Also, with netcode, netcode is all I/O code, so for the most part the seperate process would spend it's time blocked anyway. 
Torque Owner Bryan Turner
As far as I understand the netcode (and by extention any networked game), this effect does not actually modify the 'real' ping-time.. only the 'reported' ping time.
To demonstrate, take this example:
- At T0, I fire a weapon, a packet is sent to the server.
- At T50, the packet arrives at the server, is processed and sent back.
- At T100, the packet arrives back at the client but must wait for the current frame to render.
- At T140, the packet is processed and the next frame renders (which includes the projectile in flight).
The 'actual' ping time is only 100ms (from client to server and back). The reported ping time of 140 is due to the netcode pulling the packet off the queue 40ms later than it actually arrived... but notice there was NO added delay in the packet's travel time.
This would not be the case if the server was rendering a frame.. since the packet would not be processed and returned until after the frame was rendered. This is why dedicated servers are a Good Thing(tm).
--Bryan