Whether to tie qnet or not?
Last update on .
I've been working a bit on pyqnet over the weekend.
- refactored into multiple modules in a package with a setup script
- I've got a UDP-level implementation (i.e. real network level operations)
- statistics gathering is started
- the beginnings of adaptive retry/backoff code are there (i.e. resend frequency based on normal connection latency)
- fixed handling of lossy networks
- added a convenience class to specify interest groups (collections of channels).
At some point I should sit down and work on a lobby server, authentication (maybe even encryption), error handling and the like. But first I need to decide how to handle the system-integration stuff.
One option is to just tie the whole thing to Pygame, hard-code sending of Pygame events into the library. I'd prefer not to do that, as I'd like the code to be as readily adapted as possible for games that might use e.g. Pyglet or OpenGLContext for their UI. I'm tempted to use PyDispatcher for this (it being something I'm very familiar with, and the core event routing mechanism in OpenGLContext), but the dependency doesn't seem worth it, after all, I don't need extremely loose coupling, I will only be sending X events for some small value of X to some small number of GUI engines. I can do that all with a couple of sub-classes of some "event sink" class, with the appropriate event sink being passed into the network init function.
Total library download size at the moment is about 6.8KB. That's getting a bit large. Obviously people wouldn't need to download a lobby server, or test-code in their games, but they'll need the lobby client, NAT traversal code, and likely a simple payload encoder/decoder (as well as all the code I'm sure is missing in what's done so far). They'll probably also want a simple in-game-chat protocol (example). Maybe a couple of KB wasn't a reasonable target for an API with all of that functionality.
For those following along at home, the project is now up on Launchpad. This is the first time I've tried to use LP for a project. The instructions for setting up the project were a bit jargon-y, mostly figuring out that after importing my branch into my personal space I needed to then promote it to be the candidate for the trunk of the project was a bit non-intuitive. I also got a bit stuck staring at the promotion page wondering what I should type into the text box. Eventually used the search button and that worked, though it was a bit awkward.
Once you get past that, it seems reasonably nice and does seem very flexible. You can check out the code with:
bzr branch lp:pyqnet/trunk pyqnet
and if you want to work on it, join LP and branch away! One of the great things about the distributed model is that you can branch the code without permission or even awareness on my part.
Comments are closed.
Pingbacks are closed.
Pete on 07/28/2008 12:17 a.m. #
Cool stuff Mike. I'd vote against integration with Pygame events, unless it was completely optional. I don't know if using something similar to Fibra would help? http://code.google.com/p/fibranet/
Mike Fletcher on 07/28/2008 12:36 a.m. #
For the events I'm thinking of something like
from qnet import network, pygameevents
net = network.Network( observer= pygameevents.Observer())
with the only pygame-specific code being in the observer module. Need to figure out how/whether to handle callbacks and the like though.
I don't think Fibra should be necessary, we have a pretty simple threading story. The one exception is the desire to have wake-on-LAN so that if we are quiet locally we aren't burning cycles doing a network loop. I don't think Fibra will help with that.
I have a tentative plan for a way to hack that in, but it's not elegant yet (would be nice if we could pass a select-able to the GUI libs and have them only wake if they *or* the selectable is triggered).
Chris on 07/29/2008 11:45 a.m. #
I'm also against an integration with Pygame because i would like to use your library with pyglet at some point in the future.