René Dudfield <renesd@xxxxxxxxx> said:
> Iterating it at eg. 72fps means that the quickest data can go out is
> at 1/72 messages per second?
You probably don't mean this - 1/72 messages per second is awfully slow.
What I've done in situations like this before is to create an outgoing
message queue - as my game loop generates information that needs to go out
on the wire, it gets added to the queue. Then, after the game update, I do
my network "housekeeping", which sends each message from the queue out
over the network. I also spend that time to pull all waiting traffic in
off the net - could be zero, one, or many messages waiting to be processed
inbound and outbound.
> If you don't have a consistent frame rate, say a frame too 1/14th of a
> second because of some heavy graphics - then messages would only come
> out every 1/14th of a second.
Yeah, providing a queue permits spiky circumstances to be handled as soon
as possible - though you may decide to limit the amount of traffic to move
in or out. For example, if you get a LOT of network traffic all at once (a
new player entering the game, sending out a lot of initial state
information in a short period of time), it's possible that processing all
of the waiting network messages in one frame could take too long, causing
a visible frame rate drop. So, instead, you might wish to choose a maximum
number of messages to process per frame.
> Whereas if you ran twisted in another thread it would be separate of
> those concerns - and could run at a different frequency. Maybe a
> lower frequency even.
Yeah, the idea is tempting, but I'm nervous about multithreading,
particularly making sure the threads communicate correctly. There are a
number of approaches to getting that right (mutexes, lock free algorithms,
channels), but that sort of thinking hurts my brain, and I write games to
have fun. So I avoid threads unless they're far and away the best choice
for the job.
> As a bonus all your networking stuff can be handled by a separate
> CPU/Core if available.
That would be nice, but with current versions of Python (anything with a
Global Interpreter Lock - see, for example
http://docs.python.org/api/threads.html ), you're not going to get much
concurrency on multicore machines. I'm not sure, maybe there's some
benefit to be had with low-level networking I/O being processed
independently, but the python code will all be serialized (i.e. not
concurrent) because of that GIL.
If multithreaded Python networking really excites you, I suggest you take
a look at http://www.stackless.com - a modification of the Python
interpreter which permits a lot of stuff that I find fascinating, but
again, makes my brain hurt, so I've almost never tried to integrate the
ideas with game development.
I'm not saying threads can't be used to good effect, they just require my
brain to stretch in ways it's not comfortable with. If they work for you,
that's great.
-Dave LeCompte