Mailman 3 November 2006 - Twisted

[Twisted-Python] Twisted Python 0.7.0 Prerelease Testing
by Glyph Lefkowitz Aug. 5, 2021

Aug. 5, 2021

hi there, folks: I'd really like to release 0.7.0 but I would like it to be at least a little bit tested before I do so. Could those of you with CVS trees check everything out and see if it performs as advertised? Deeper bugs than that will have to wait for the next release, but I'd at least like to know if it works for someone other than me. Thanks. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/

4 5

[Twisted-Python] Get IP of connecting client in XMLRPC server
by Remy C. Cool April 28, 2013

April 28, 2013

Hello, On 18 May 2004, the following message was posted to this mailinglist: Jp Calderone exarkun at divmod.com wrote: >Daniel Newton wrote: > > I have a simple XML-PRC server similar to the example below: > > from twisted.web import xmlrpc, server > > class Example(xmlrpc.XMLRPC): > """An example object to be published.""" > > def xmlrpc_add(self, a, b): > """Return sum of arguments.""" > return a + b def xmlrpc_whatIsMyAddress(self): return self.transport.getPeer().host > > if __name__ == '__main__': > from twisted.internet import reactor > r = Example() > reactor.listenTCP(7080, server.Site(r)) > reactor.run() > > I want to be able to get the address of the client that calls the xmlrpc > method can anyone help me with this? This solution didn't work because 'transport' isn't a property of the Example class. I'm currently in the process of changing from a customized SimpleXMLRPCServer to a twisted XMLRPC server solution and I need to insert the client IP into the attributes passed to the called xmlrpc method. Anyone who knows the answer and is willing to share the info? Regards, Remy

3 3

[Twisted-Python] Reconnecting PB Client
by Don Smith Sept. 12, 2007

Sept. 12, 2007

Does anyone have some example code for building a reconnecting PB client? This is what I have now: from twisted.spread import pb from twisted.internet import reactor from twisted.python import util events = pb.PBClientFactory() reactor.connectTCP("localhost", 8789, events) queue = events.getRootObject()

3 2

[Twisted-Python] Producers / Consumers and more examples tutorials?
by jarrod roberson March 13, 2007

March 13, 2007

Are there any more concrete examples or tutorials of using Producers and Consumers?

3 5

[Twisted-Python] Support for ICMP ping?
by Nicolas D. Cesar Feb. 8, 2007

Feb. 8, 2007

I've been googling if there is any 'ICMP ping' support in Twisted. I've encounter ancient replies: http://twistedmatrix.com/pipermail/twisted-python/2003-August/005542.html I wonder if today is any ICMP support. I've tried to search the source tree[1], and doesn't seem. My actual needs is creating a DeferredList with "ping-testers" for different IPs, just to check if there up or not. I know I can end up using twisted.internet.utils.getProcessOutput and calling ping, as I would normally do from command line. For other newbies as me in the same situation please read: http://twistedmatrix.com/users/moshez/talk.html and search for 'getProcessOutput' ;-) Greetings, [1] my search was: -------------------------------------------------------------------- $ grep -C3 -ir icmp * internet/protocol.py- internet/protocol.py- internet/protocol.py-class AbstractDatagramProtocol: internet/protocol.py: """Abstract protocol for datagram-oriented transports, e.g. IP, ICMP, ARP, UDP.""" internet/protocol.py- internet/protocol.py- transport = None internet/protocol.py- numPorts = 0 -- internet/protocol.py- def connectionRefused(self): internet/protocol.py- """Called due to error from write in connected mode. internet/protocol.py- internet/protocol.py: Note this is a result of ICMP message generated by *previous* internet/protocol.py- write. internet/protocol.py- """ internet/protocol.py- -------------------------------------------------------------------- -- Nicolás D. César <ncesar(a)lunix.com.ar> Lunix S.R.L. -[ http://www.lunix.com.ar ]- GnuPG Public Key: gpg --keyserver wwwkeys.pgp.net --recv-key 0x3606F3E6

5 7

[Twisted-Python] Problem: spawnProcess() never ending when installSignalHandlers=False
by Matt Feifarek Feb. 3, 2007

Feb. 3, 2007

Hello. I'm using Twisted 1.3.0 on python2.4 on an Ubuntu-Hoary x86 Linux box. I'm using twisted and spawnProcess() with a Queue structure to chain processes that need to be called (specifically, imagemagick commands). I use the "processEnded" event/method of t.i.p.ProcessProtocol to go from one task to the next. Twisted shares a python process with a multi-threaded web-app-kit (Webware) so it has to be run in a thread. This worked well on other older versions of twisted and older versions of python; also on linux. I've tracked down the problem to be twisted itself (or my incorrect use of it) rather than my code. This example illustrates it: ------------------------------------------------- from twisted.internet import reactor from twisted.internet.protocol import ProcessProtocol class MyProt( ProcessProtocol ): def processEnded(self, reason): print "ended.", reason executable = '/bin/touch' args = ( '/tmp/foo.txt', ) args = (executable,) + tuple(args) reactor.spawnProcess( MyProt(), executable, args ) reactor.callLater( 5, reactor.stop ) #reactor.run() reactor.run(installSignalHandlers=False) ------------------------------------------------- As is, this code never runs the "processEnded()" method of MyProt(). If I change the reactor.run() parameter to leave the signal handlers on, it works. Note that I need to leave the signal handlers turned off because I can't run the reactor in the main thread; Webware needs that. I also know that the subprocess is giving up its file descriptors; I can see that if I put more print statements into MyProt(). And I know that the subprocess is working; /tmp/foo.txt is there. It seems that somehow the reactor is using signals to notice when a process has ended; this makes a certain ammount of sense intuitively, though I don't understand the nitty-gritty of processes and signals at all. And more importantly, this has worked before on other combinations of twisted/python. Is this a bug? If so, has it been fixed? If not, what should I do to detect when a spawned process is finished? Thanks very much. Twisted rocks.

6 14

Re: [Twisted-Python] trac's reliability
by glyph＠divmod.com Dec. 1, 2006

Dec. 1, 2006

On 27 Nov, 07:04 pm, foom(a)fuhm.net wrote: >The other option is to upgrade wolfwood to debian stable ("sarge") and then >just install svn 1.4 from testing. That might be a good idea anyhow, since >oldstable is, well, old. And unsupported. It would be good to know, for the purposes of such discussions, who the official admin of these hosts is. If I knew, I'd ask that person to please upgrade everything to Dapper, thanks to its long updates support cycle and my relatively stable experience with it. Without knowing who it was and how long it's going to take though, it's hard to make suggestions.

5 6

Re: [Twisted-Python] Need Exception that will stop ther reactor within twistd
by glyph＠divmod.com Nov. 30, 2006

Nov. 30, 2006

On 27 Nov, 06:19 pm, ncesar(a)lunix.com.ar wrote: >El S�bado, 25 de Noviembre de 2006 02:39, glyph(a)divmod.com escribi�: >> >I was wondering if twistd/the application class could have a "exit on >> >Exception" for this type of operations. >> In general this is a bad idea. There are basically 3 kinds of code you can >> write with Twisted: >> >> 1. Infrastructure code, which implements a protocol and provides APIs for >> parsing and dealing with events. This kind of code should never contain a >> reactor.stop at all. >Actually is type 1, but there are horrible (network) conditions were de >application should stop. No, there aren't. What happens when I run your application in-process with my webserver? Should the webserver stop simply because your protocol is not working? >Even it's not type 3, I get your point. And thats why I didn't want to write >ANY reactor.stop() call, instead just raise exceptions- And have a unnified >reactor.stop() inside somewhere in twistd. But it seems I need to think >another solution. Right now as a workaround, reactor.stop() will be inside my >exception's __init__ function ;-) Just don't call reactor.stop at all unless you are writing top-level infrastructure code. Your application should have some other, more structured way of reporting fatal shut-down errors to its run container (e.g. runContainer.applicationEncounteredFatal(xxx)), not simply raising exceptions and hoping someone is listening. Unless you give more specifics that indicate that your special case is special-er than any other I've seen before, I'll stand by this. :) >> Don't try to always stop the *process* when your program is >> complete: stop the *program* by keeping a Deferred around which represents >> its complete run. That way the *driver* for the program is responsible for >> stopping it, and when you want to aggregate multiple runs of it, you can >> easily use a tool like DeferredList, or do something different in the >> callbacks at the end. > >I couldn't understand much of this last parragraph (my English reading could >be part of the problem). I understand algorithms mucho more when are written >in python instead of English, Do you have a link to some code explaning >this? It's hard for me to think of a program which does this in a simple way. If I can think of one I will post an example.

2 1

[Twisted-Python] downloading the code of the FIXED lore so that I can use it to output multi-chapter lore source to latex
by Dominik Margraf Nov. 30, 2006

Nov. 30, 2006

I need to process the thinkCSpy ebook lore source to latex urgently, however there is a bug in the curent stable version which prevents compiling spanned chapters. http://twistedmatrix.com/trac/ticket/2134 which is fixed very recently but doesn't yet seem to be merged with the trunk (I have downloaded the svn trunk and tried its lore, but still has the same bug) Can anyone give me (or point to the place where I can download) the updated file so that I can do my job immediately? Thanks! Dominik

2 1

Re: [Twisted-Python] blockingCallFromThread, ticket 1042
by glyph＠divmod.com Nov. 29, 2006

Nov. 29, 2006

On 06:47 pm, markus(a)bluegap.ch wrote: >A long time ago, I've been asking about a blocking callFromThread function >and have been pointed to ticket 1042 at [1]. What's the state on that? Does >that have a change of being integrated into twisted? At the very least, the function there needs tests, documentation, and a use-case for some code that is going to want to call it from within Twisted - and I don't think there is any currently. There are probably a few things that are painful to do without such a function, but in general this sort of thing is just a recipie for deadlocks and running out of threads in your pool, so I am not inclined to push it forward.

1 0

[Twisted-Python] blockingCallFromThread, ticket 1042
by Markus Schiltknecht Nov. 29, 2006

Nov. 29, 2006

Hi, A long time ago, I've been asking about a blocking callFromThread function and have been pointed to ticket 1042 at [1]. What's the state on that? Does that have a change of being integrated into twisted? Regards Markus [1]: http://twistedmatrix.com/trac/ticket/1042

1 0

Re: [Twisted-Python] trac's reliability
by glyph＠divmod.com Nov. 29, 2006

Nov. 29, 2006

On 05:53 am, foom(a)fuhm.net wrote: >Current trac status: >more or less working. On behalf of everyone using Twisted's trac, thanks a lot for putting some work into this. :)

1 0

Re: [Twisted-Python] trac's reliability
by exarkun＠divmod.com Nov. 29, 2006

Nov. 29, 2006

On 12:31 am, jml(a)mumak.net wrote: >Hello, > >The reliability of our trac instance is ludicrous. It is becoming >extremely difficult to do any work on Twisted, particularly during the >hours when America is asleep. > >I'm very grateful for Jp's tireless efforts in making trac work as >much as it has. I have some idea of how busy he is, and can imagine >how frustrating the task must be. However, we can't continue running >our issue tracker like this. > >First question is, what is causing the outages? People on #twisted >have commented that they haven't seen similar behaviour on their own >tracs. The outages are so frequent that this is becoming an FAQ. There are several problems: Segfaults in the svn bindings - in correspondence with the trac team, I have been told (almost in so many words) that bdb-backed svn repositories are unsupported and we should switch to fsfs. Segfaults in the SQLite bindings - likewise, in correspondence with the trac team, I have more or less been told that SQLite is not a supported database engine and that we should switch to PostgreSQL. Deadlocks in... who knows where. > >The second question is, how can I help trac to work better? Would it >help to throw more hardware at the problem? Should we switch to >another tracker? (blech) Are there open tickets on trac itself that I >could submit patches for? It might be possible to resolve the above mentioned problems. If we convert the repository to fsfs, we might find the segfaults from the svn bindings disappear (of course, we might not - I think we can all recognize the quality of this sort of bug stomping). In addition to the actual task of converting, involved in this would be some level of investigation into the level of stability of the fsfs backend available in the version of debian used on wolfwood, an effort to package or have packaged a newer version, or an upgrade of wolfwood (however, since even edgy lacks svn 1.4, this probably isn't a useful endeavour). This may also involve recompiling several packages on pyramid to add fsfs support or remove bdb support. If we convert the trac database to use PostgreSQL, the SQLite segfaults will hopefully go away. ;) This involves setting up a PostgreSQL server which we can use for trac (one is running on pyramid now, for the benefit of buildbot, beyond that, what state it is in is not clear to me). There is a tool available from edgewall which is supposed to be capable of moving data from a SQLite database to a PostgreSQL database. The various scripts and utilities which we have (eg, the weekly bug summary) may also need to be adjusted (I forget to what extent they are tied to SQLite). Then, as an ongoing task, someone will need to maintain the PostgreSQL server. As for the random deadlocks which occur... I see no realistic course of action which is likely to resolve these. Perhaps, if the above changes are enacted, we will be lucky they will just go away by themselves. That seems to be the attitude of the trac developers, anyway. > >Finally, assuming Twisted's trac isn't going to get much better any >time soon, I would greatly appreciate being given the permissions and >training to restore trac. I think it would also be a good idea to >share the responsibility with someone in a European timezone. Before I left last week I set up a cron job to take care of this. When I returned it was still doing its job, so the level of availability seen over the past week or so may be the highest we can expect until we do something else fundamental to fix the issue. However, the SSH key you gave me long ago is still in place and you should still have access to restart the server (just connecting should do it). Personally, I am in favor of switching away from trac, as I have been since shortly before we adopted it. ;) The only open question is when the replacement will be ready. Jean-Paul

9 11

[Twisted-Python] Why I have not gotten any mail in this list?
by Steve Han Nov. 29, 2006

Nov. 29, 2006

Anyone help me?

1 0

[Twisted-Python] Perspective Broker
by le dahut Nov. 28, 2006

Nov. 28, 2006

Hello, Using PB, I've setup a system where clients can control other clients in this way : client1 executes "remote_do_something" on server1 with "ip_client2" as argument. Then server1 connects to client2 and executes "remote_smthng" on it. code is like this : - client1: """ factory = pb.PBClientFactory() reactor.connectTCP(ip_server1, port, factory) d = factory.getRootObject() d.addCallback(lambda object: object.callRemote("do_something", ip_client2)) d.addCallback(client1_call_b) d.addErrback(client1_err_b) """ - server1: """ def remote_do_something(ip): factory = pb.PBClientFactory() reactor.connectTCP(ip_client2, port, factory) d = factory.getRootObject() d.addCallback(lambda object: object.callRemote("smthng")) d.addCallback(server1_call_b) d.addErrback(server1_err_b) """ - client2: """ def remote_smthng(): <code> return "Ok, everything's done" """ How can client1 get client2's answer ? Thanks

2 2

Re: [Twisted-Python] SQLAlchemy integration
by Ed Suominen Nov. 27, 2006

Nov. 27, 2006

>>> I'm writing some modules for integrating SQLALchemy with Twisted. >>> The idea is to write a custom Pool, EngineStrategy and Engine for Twisted. >>> I would like to know if there are some other people working on this >>> (excluding sAsync) >> Is there really a good reason for having *two* different efforts to >> integrate Twisted with a single other library? Surely it must be >> possible to collaborate somehow. I agree with Glyph. I've put a ton of effort into sAsync, which would cost thousands of dollars at even a fraction of what I charge for "real" work. Why not make use of that? It is GPL'd, but I have one user implementing it in a commercial project now under a special license that he obtained by doing some coding of his own for me. (My thanks to the Twisted developers for making Twisted itself available under a no-strings-attached license, and thus providing me the opportunity for that sort of modest compensation.) > This works because Engine implements the Connectable interface. > There is an issue here: if a query/table is bound to this Engine, every > query will run in a separate thread; this is not what one want when > inside a transaction). Perhaps you should take a closer look at what sAsync does before dismissing it. sAsync has a taskqueue module that it uses to queue up transactions so that they are *all* run in a single, dedicated thread. > More complex is the integration with sqlalchemy session handling. > > As an example with Nevow: > - a thread retrieve an object from the database > - another thread modify the object > > It would be much simple if the two operations occur in the same thread > (this require to run renderHTTP or locateChild in a separate thread but > I ignore if this is safe). Again, the two operations *do* run in the same thread under sAsync, as do all other SQLAlchemy operations that are run via methods of AccessBroker. All you have to do is decorate the method with @transact and it will run via the queue and the dedicated thread. So, you may not want to re-invent the wheel on this one. By the way, I try to be responsive to user comments, ideas, and patches. Some have already improved sAsync quite a bit. Best regards, Ed Suominen Developer of sAsync: http://foss.eepatents.com/sAsync

3 2

Re: [Twisted-Python] Need Exception that will stop ther reactor within twistd
by glyph＠divmod.com Nov. 27, 2006

Nov. 27, 2006

On 12:55 am, ncesar(a)lunix.com.ar wrote: >> This is bad form, however. Particular types of exception should not stop >> the reactor. Code that wants the reactor to stop, should call >> reactor.stop. Maybe you could make a method that both calls reactor.stop() >> *and* raises an exception. > >This is the way i'm doing it right now, but i'm starting to detect new >exceptions raised within standard library (among others) code... and instead >of catching all posibilities I wanted the application to quit (with the >corresponding logging done). > >I was wondering if twistd/the application class could have a "exit on >Exception" for this type of operations. In general this is a bad idea. There are basically 3 kinds of code you can write with Twisted: 1. Infrastructure code, which implements a protocol and provides APIs for parsing and dealing with events. This kind of code should never contain a reactor.stop at all. 2. Application code which exits in response to a particular user event. This kind of code should contain exactly 1 call to reactor.stop, in the handler for the user event that is the explicit stop. 3. Programs which do one operation, then stop themselves. This kind of code should contain exactly 1 call to reactor.stop, in the final callback/errback of the Deferred representing the operation that it is run to perform. It sounds like you are writing code of type 3. I'm guessing you're writing a program which does one thing, then shuts itself down. If that is the case, the "program" should be encapsulated by a Deferred, and there should be a final addBoth which waits for the program to finish when it exits. If you *don't* structure your program this way, then you'll discover later that sometimes, you want to run your particular operation TWICE in the lifetime of the process instead of once, and you will have to deal with dozens of calls to reactor.stop littered around your application in lots of places. Don't try to always stop the *process* when your program is complete: stop the *program* by keeping a Deferred around which represents its complete run. That way the *driver* for the program is responsible for stopping it, and when you want to aggregate multiple runs of it, you can easily use a tool like DeferredList, or do something different in the callbacks at the end.

2 1

Re: [Twisted-Python] SQLAlchemy integration
by Maciej Szumocki Nov. 27, 2006

Nov. 27, 2006

> Date: Thu, 23 Nov 2006 07:39:58 -0000 > From: glyph(a)divmod.com > Subject: Re: [Twisted-Python] SQLAlchemy integration > To: Twisted general discussion <twisted-python(a)twistedmatrix.com> > Message-ID:> <20061123073958.22613.1053884361.divmod.xquotient.5(a)joule.divmod.com> > Content-Type: text/plain; charset="utf-8" > > On 22 Nov, 11:19 am, manlio_perillo(a)libero.it wrote: > > >I'm writing some modules for integrating SQLALchemy with Twisted. > >The idea is to write a custom Pool, EngineStrategy and Engine for Twisted. > > >I would like to know if there are some other people working on this > >(excluding sAsync) > > Is there really a good reason for having *two* different efforts to > integrate Twisted with a single other library? Surely it must be possible > to collaborate somehow. I also use both Twisted and SQLAlchemy in one project. Unfortunately, using sAsync is not an option for me due to licensing issue (sAsync is released under GPL). Maciej Szumocki

1 0

Re: [Twisted-Python] Using Conch as a ssh server on MS Windows
by glyph＠divmod.com Nov. 27, 2006

Nov. 27, 2006

On 09:27 am, rasjidw(a)gmail.com wrote: >I'll probably stick with stdin/stdout, at least initially, as I have >done something along these lines before, just not within the twisted >framework. Previously I used threading and emulated a non-blocking >process through buffering the data read. I've been looking into >non-blocking pipe reading in win32, and it looks like there are a >coule of choices. Possibly the easiest I've seen so far uses some >calls from wxWidgets which adds another dependancy but seems to give >more control. If you're going to use stdin/stdout, just use the Twisted reactor's "spawnProcess" method, as the UNIX version of Conch does (although without the "pty" feature). A great deal of trouble has already been put into making the Windows version of Twisted behave as if the operating system actually supported asynchronous interprocess communication.

2 1

[Twisted-Python] trac's reliability
by Jonathan Lange Nov. 27, 2006

Nov. 27, 2006

Hello, The reliability of our trac instance is ludicrous. It is becoming extremely difficult to do any work on Twisted, particularly during the hours when America is asleep. I'm very grateful for Jp's tireless efforts in making trac work as much as it has. I have some idea of how busy he is, and can imagine how frustrating the task must be. However, we can't continue running our issue tracker like this. First question is, what is causing the outages? People on #twisted have commented that they haven't seen similar behaviour on their own tracs. The outages are so frequent that this is becoming an FAQ. The second question is, how can I help trac to work better? Would it help to throw more hardware at the problem? Should we switch to another tracker? (blech) Are there open tickets on trac itself that I could submit patches for? Finally, assuming Twisted's trac isn't going to get much better any time soon, I would greatly appreciate being given the permissions and training to restore trac. I think it would also be a good idea to share the responsibility with someone in a European timezone. Thanks, jml

1 0

[Twisted-Python] Using Conch as a ssh server on MS Windows
by Rasjid Wilcox Nov. 26, 2006

Nov. 26, 2006

I would like to have occasional remote admininitrative command line access to a number of MS Windows machines that I help maintain. There are over 200 machines, but usage would be very limited and sparodic, so the commerical solutions are too expensive for the benefit gaiined. Windows XPs built in telnet server is free, but insecure. And if possible, I would like to avoid the Cygwin route, particulary on machines that I don't have physical access to. So has anyone used the ssh server in Conch as a secure way of providing command line access a Windows machine? Cheers, Rasjid.

2 2

[Twisted-Python] Weekly Bug Summary
by exarkun＠twistedmatrix.com Nov. 26, 2006

Nov. 26, 2006

Bug summary ______________________ Summary for 2006-11-19 through 2006-11-26 Bugs opened: 6 Bugs closed: 3 Total open bugs: 783 (+3) |== Type Changes |== Priority Changes |== Component Changes |Defect: +2 |Highest: -1 |Core: +0 |Enhancement: +1 |Normal: +4 |Mail: +1 |Low: +0 |Trial: +0 |Web2: +1 |Website: +1 New / Reopened Bugs ______________________ ===== Highest ===== [#2240] Add twisted.mail SMTP client example which demonstrates TLS and authentication (opened by exarkun) enhancement mail http://twistedmatrix.com/trac/ticket/2240 ===== Normal ===== [#2241] Trac emails suck, they don't provide a link to the website. (opened by jerub) defect website http://twistedmatrix.com/trac/ticket/2241 [#2242] twisted.web2.static.File sucks with regards to overriding it's content type (opened by dreid) defect web2 http://twistedmatrix.com/trac/ticket/2242 [#2243] Todo attribute checking (opened by mithrandi) enhancement trial http://twistedmatrix.com/trac/ticket/2243 [#2244] Patch to setup.py to work with python installs in directories containing a space (opened by Sandra24) defect core http://twistedmatrix.com/trac/ticket/2244 ===== Low ===== [#2245] Deferred implementation in C (opened by therve) (CLOSED, invalid) enhancement core http://twistedmatrix.com/trac/ticket/2245 Closed Bugs ______________________ ===== Highest ===== [#2173] twisted/trial/runner.py:243: exceptions.DeprecationWarning: log.startKeepingErrors is deprecated since Twisted 2.5 (opened by exarkun, closed by jml, fixed) defect trial http://twistedmatrix.com/trac/ticket/2173 [#2212] Remove mention of threadable.init from the threading chapter (opened by radix, closed by radix, fixed) enhancement core http://twistedmatrix.com/trac/ticket/2212 ===== Low ===== [#2245] Deferred implementation in C (opened by therve, closed by exarkun, invalid) enhancement core http://twistedmatrix.com/trac/ticket/2245

1 0

Re: [Twisted-Python] Keeping a list of connected PB clients
by Phil Christensen Nov. 26, 2006

Nov. 26, 2006

On Nov 24, 2006, at 5:16 PM, Yi Qiang wrote: > On 11/19/06, Phil Christensen <phil(a)bubblehouse.org> wrote: > On Nov 19, 2006, at 7:00 PM, Yi Qiang wrote: > > There does not seem to be a corresponding clientConnectionLost > > method for the Factory class. Any suggestions would be appreciated. > > My approach to this was to put any post-connection cleanup in the > Avatar's "logout" method. > > Hi Phil, > Do you happen to be able to share the code you've written to > accomplish just this? Where do you store your list of connected > clients? I'm CC'ing the list for posterity, but this is actually pretty straightforward. I'm guessing the issue is that you're over-thinking this. First of all, here's some code from your original post: On Nov 19, 2006, at 7:00 PM, Yi Qiang wrote: > from twisted.spread import pb > > class DSagePBServerFactory(pb.PBServerFactory): [snip snip snip] > def clientConnectionMade(self, broker): > self.clients.append((broker.transport, > broker.transport.getPeer().host, > broker.transport.getPeer().port)) > print self.clients First thing, there's not necessarily any need to subclass the PBServerFactory if this is all you're doing. In the interest of forward-compatibility (always a good idea with Twisted ;-), I try to avoid making subclasses of essential framework classes unless I have a very good reason (or a very bad one ;-). The place where you want to do all this is really in your Realm instance. I think it's possible to create a PB server that doesn't require login, but I've never had any need for it, so you're kind of on your own there. > class MyRealm: > """ > Holds a reference to the main service object. > """ > __implements__ = portal.IRealm > > def __init__(self, service): > """ > Create a realm with the given service. > """ > self.service = service > > def requestAvatar(self, avatarId, mind, *interfaces): > """ > This function is called after the user has verified their > identity. It returns an object that represents the user > in the system, i.e., an avatar. > """ > if pb.IPerspective in interfaces: > avatar = self._getPBAvatar(avatarId, mind) > ####################### <-- RIGHT HERE > return pb.IPerspective, avatar, avatar.logout > else: > raise NotImplementedError("no interface") This is where you want to maintain your client list. The hardest part is deciding on a place to put it that will be accessible from all your code; I usually use a singleton pattern of some kind, where I can import a module that holds onto client references and provides functions to manipulate/retrieve that list. So, that point where I put all those hashes is a pretty good place to add clients your client queue. The 'mind' argument is usually a reference to the client on the other end, assuming your client passes it properly. My client does this: > # self.client is a Referenceable on the client side. > defer = self.factory.login(credentials.UsernamePassword > (username, password), self.client) > defer.addCallback(connected_callback, self) This way, you can find all the necessary info you might need to identify the user on the other end in the properties of this object. You'll also see that right after the hashes, I return a three-tuplet that has avatar.logout as its third item. This is a method defined on my avatar object, but any callable object can be returned here, and that callable, of course, can remove clients from your list. So one approach to keeping track of client connections would be: > class MyRealm(pb.Avatar): > # ... snip > # ... snip > def requestAvatar(self, avatarId, mind, *interfaces): > """ > This function is called after the user has verified their > identity. It returns an object that represents the user > in the system, i.e., an avatar. > """ > if pb.IPerspective in interfaces: > avatar = MyAvatar() > > import clienttracker > clienttracker.append(avatar) > > return pb.IPerspective, avatar, avatar.logout > else: > raise NotImplementedError("no interface") > > class MyAvatar(pb.Avatar): > # ... snip > # ... snip > def logout(self): > import clienttracker > clienttracker.remove(self) There's a lot of flexibility there. You could move the clienttracker.append call right inside your Avatar constructor -- the only reason I didn't is because my server supports a number of protocols besides PB, and I wanted to deal with them universally. One thing this approach doesn't do is keep track of clients that connect, but fail authentication. To do that, you'd need to subclass Broker, but that's a tough one. I looked into this once before, and it certainly appears doable -- in the end, a Broker is still a Protocol, which means it has a transport property you can get client addresses out of. Of course, if a user fails authentication, they are immediately disconnected, so this would only be a problem if you are concerned about malevolent users. It would be possible to write a client that connects but never authenticates; enough of those could cause some discomfort on the server side, but if that happens, you likely have more problems than keeping track of a client list. Hope this helps... -phil

2 2

Re: [Twisted-Python] Anyone added NAPTR support to Twisted Names ?
by glyph＠divmod.com Nov. 25, 2006

Nov. 25, 2006

On 07:06 pm, roland.hedberg(a)adm.umu.se wrote: >If anyone wants the fix I can send you a diff. Please open a ticket in the Twisted tracker for further discussion, and attach your patch there - hopefully with tests :).

1 0

[Twisted-Python] Anyone added NAPTR support to Twisted Names ?
by Roland Hedberg Nov. 25, 2006

Nov. 25, 2006

Hi! There is no support what I can see in the present distribution, but someone might have needed it and done a local patch. I've made a not so well thought out attempt to add it myself, but I my client (dig) responds with "Warning: Message parser reports malformed message packet." So, I'm obviously made some error. Anyone that can lend me a hand ? -- Roland

1 2