Hello all,
I am working on my online game client framework. I did a small prototype in WindowXP doing something like:
Thread A: Checking on the shared Queue.
If something is in the Queue then
send it to a UDP server and wait for response (UDP)
Otherwise, keep checking (blocking).
World class:
with similar things done like the Roaming Ralph
example other than putting move actions into the
shared Queue to be sent.
Main program:
Start the thread A
instantiate the World class
Invoke Panda3d’s run()
wait for thread A to complete
Everything works as I wanted in WindowXP. When I copy the code to Linux (installed with the Panda3D same version and same version of Python). The sendto() and recv() seems to lag a lot.
I then try to find out what went wrong, it appears the server is responding fast and well, the client seems to be where the lag starts. I did some researches and someone indicated back in 2007 saying Python got a similar lag happening in Linux due to differences in TCP stack implementation. Welp, in order to remove that possibility, I commented out the Panda3d code so the World class is not instantiated and the run() did not get called. I dumped about 100 entries in the shared Queue, thread A processed them (sent and recv) properly without any lags!!
This said, do anyone of you had this similar issue? What will be a good solution on this? I would like to get my framework working in the Linux more than in WindowXP. Please let me know what you think, thanks in advance.
BTW, I don’t like to use the frame rate to regulate the message processing, thus I did not use the network facility came with Panda3d. Just FYI.
But the frame rate still regulates how you process your messages because threads don’t run in parallel in panda3d and threads are a bad idea in python in general.
Assuming one user got a bad video card and the other got a top notched card, who’s message fired first? this is one reason I don’t like to tie the message processing with frame rate. If I can do this in a thread (send and receive) I might be able to regulate the messages speed by a timer evenly.
Python is a new skill for me, I am not sure why the threading is a bad idea with Python. I might be wrong but it appears Python devoted a lot of efforts in it (I been digging a lot in 2.7.1 online manual lately).
Anyway, I guess this is not the main issue I got. My main issue is the differences in Window and Linux and how to resolve this. Maybe there’s a way to hook my thread(s) inside the run() method? btw, Thanks for your feedback treeform
But input is frame dependent? And what user with bad gfx card saw is also frame dependent. Your life would have been easer if you stick with standard panda3d things.
Are you sure the lag is in the sendto and resv? Did you put a timer around them? Also doesn’t resv block in your case or are you using select?
Yes, the recv blocks (per Python’s socket).
You are right, only during frame refresh, the user action will be detected and log to send. However, during that period of time, it is possible other users’ action msgs will arrive. My thread can catch that situation.
The lag occurs in thread(s) send/recv plus other things like printing messages, anything done in the thread domain seems to lag while Panda3d’s renderer was happily running without any lag and putting action messages to be sent in the shared Queue. The server is fine, no lag responding to the client (maybe since its has no Panda code in it), it is just a plain UDP echo server for this prototype framework.
While the same code ran as expected without any lag in XP, I might have to decide to go just with XP (sig…) or use Panda3d provided network facility if I can’t find a solution on this.
Note that, by default, Panda is compiled with SIMPLE_THREADS enabled, which means that you don’t get true os-provided threading support for things like socket send and receive. This is good for making it easier to write threads that don’t deadlock or crash, but it’s bad when you want to write threads that make direct system calls to handle I/O.
In order to solve this problem with your current code design, you will need to compile your own Panda with SIMPLE_THREADS disabled, so that you get full os-provided threading.
Or, you can just use Panda’s networking interfaces instead of Python’s or some other system’s. Panda’s networking interfaces are designed to work with SIMPLE_THREADS.
