prologic at shortcircuit.net.au
Fri Dec 12 03:02:21 CET 2008
Have a look at circuits.
It's a general purpose event-driven framework
with a focus on Component architectures and
has a good set of Networking Components,
* UDPClient (alias of UDPServer)
With circuits, there is no such thing as: serve_forever()
It'll try to stay out of your way as much as possible
and let you define your own main event loop which
could look like this:
from circuits import Manager
from circuits.lib.sockets import TCPServer, TCPClient
manager = Manager()
client = TCPClient()
manager += server
manager += client
I hope this helps you! :)
On Fri, Dec 12, 2008 at 10:33 AM, Emanuele D'Arrigo <manu3d at gmail.com> wrote:
> Hi everybody! A networking question!
> I've been looking at and tinkering a little with the various
> networking modules in python. The examples are pretty clear and a
> module such as the SimpleXMLRPCServer is actually simple!
> All the examples though are based on a client interrogating a server,
> with the client initiating the connection, obtaining something and
> then closing the connection. Basically the server is a reactive party:
> only if the client get in touch the server respond. What if the server
> wanted to notify the client of something of interest, i.e. new data
> that the client should take into consideration and potentially
> One option would be for the client to periodically poll the server for
> changes. Fair enough, that would work. But it'd be a bit of a waste if
> the changes aren't particularly frequent.
> Is it possible then to establish both a server and a client in the
> same application? I guess it must be possible but the examples all
> rely on some kind of server loop (i.e. SocketServer.serve_forever)
> that if started on both client and server sides would create two
> listening parties but no talking at all! Furthermore, other libraries
> might have their own loop, i.e. a graphical client has a loop to
> redraw the screen and the two loops would somehow have to be
> I'm not quite seeing how this can be done other than we threads. Is
> that the way to do it? Place the listening loop in a thread while the
> rest of the application does its own thing?
> Or is it SocketServer.handle_request() the key? I could call this
> function periodically, but what happens if a request is made while the
> application is doing something else? Are the requests queued and dealt
> with one per loop?
> Thanks for your help!
-- "Problems are solved by method"
More information about the Python-list