Mailman 3 July 2012 - Twisted

[Twisted-Python] SIP protocol Via header doesn't compatible with SIP RFC3261.
by RuiQiang Huang July 6, 2012

July 6, 2012

Via header is different between RFC2543 and RFC3261. Based on RFC3261, Via header BNF is Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = "ttl" EQUAL ttl via-maddr = "maddr" EQUAL host via-received = "received" EQUAL (IPv4address / IPv6address) via-branch = "branch" EQUAL token via-extension = generic-param That means parseViaHeader should return a tuple, instead of single via object. Top via will be parse first via header and first element in the tuple. This fix is required because if message coming from Via, and it inject Via header like this Via: SIP/2.0/UDP 192.84.13.26:5060;branch=z9hG4bK5af66076b7a656376f671478bb7a4b3f,SIP/2.0/UDP 192.168.1.145;branch=z9hG4bKfbbb8cf0FF120663;received=192.84.17.215;rport=13582 current SIP stack cannot send the response to 192.84.13.26:5060. Instead, it sends to 192.84.13.26:13582 that never get to the other side. So I fixed this to have my SIP program working with proxy. I have a patch for this. Please let me know how to submit to SVN. Thanks.

2 1

[Twisted-Python] Twisted sprint and tutorial in San Francisco
by Ying Li July 6, 2012

July 6, 2012

Hi all! There will be a Twisted tutorial/learning session in San Francisco on Friday, July 13th, at 7pm. Glyph will be giving the tutorial, and several developers will be on hand to help. There will be a Twisted sprint the next day, Saturday July 14th, from 10am to 9pm (or later, if folks want to stay later!) - come whenever and for however long you like. Hack on Twisted or a Twisted-related project, learn more about how to use Twisted, or just hang out. Both events are hosted at Rackspace, which is located at 620 Folsom St, Suite 100, San Francisco 94107. (between 2nd St and Howard, or 2nd and 3rd if you prefer). Please RSVP at: http://www.meetup.com/San-Francisco-Twisted-Python-Meetup (so we know how much food and drink to get!) Thanks! -Ying

1 0

[Twisted-Python] How to get the socket error when NIC is down
by Peng Xiao -X (penxiao - Digital China at Cisco) July 5, 2012

July 5, 2012

Hi experts, I wrote a TCP program using twisted, and the TCP socket bind the local IP address, the code can reconnect TCP connection when TCP is disconnected. But the program will be exit without any error when the local NIC is down. I want to know how can I capture the exception when the local NIC is down? Thanks a lot. Best Regards, Xiao Peng(肖鹏)

2 1

Re: [Twisted-Python] ANN: Twisted DBus 1.0 => WebSocket/WAMP Bridge
by Tobias Oberstein July 4, 2012

July 4, 2012

Hi Tom, Great! I have created a quick example that bridges WebSocket/WAMP and Dbus https://github.com/tavendo/AutobahnPython/tree/master/examples/wamp/dbus This allows to trigger desktop notifications on one or multiple machines from a browser based UI running anywhere via a WebSocket/WAMP PubSub message broker in between. Cheers, Tobias Mit freundlichen Grüssen, Tobias Oberstein Geschäftsführer +49(0)9131 940 3574 +49(0)176 23 752 055 tobias.oberstein(a)tavendo.de skype: tobias.oberstein Tavendo GmbH · Am Weihersbach 13 · 91074 Herzogenaurach · Deutschland Office / Postanschrift : Waldstrasse 18 · 91054 Erlangen · Deutschland +49(+)700 GO TAVENDO · +49(0)700 46 828 36 36 · www.tavendo.de Amtsgericht Fürth · HRB 10365 · USt-Id.Nr DE246462916 · Geschäftsführer Tobias Oberstein > -----Ursprüngliche Nachricht----- > Von: twisted-python-bounces(a)twistedmatrix.com [mailto:twisted-python- > bounces(a)twistedmatrix.com] Im Auftrag von Tom Cocagne > Gesendet: Dienstag, 3. Juli 2012 22:37 > An: Twisted general discussion > Betreff: Re: [Twisted-Python] ANN: Twisted DBus 1.0 > > Nevermind. Simply removing the explicit credential passing from the client side > of the implementation fixed the problem. txdbus 1.0.2 appears to run just fine > on 12.1. > > Tom > > On Tue, Jul 3, 2012 at 10:14 AM, Tom Cocagne <tom.cocagne(a)gmail.com> > wrote: > > Unfortunately, it looks like 12.1 may be completely incompatible with > > txdbus. The ancillary data support for Unix sockets appears to support > > only file descriptor passing and breaks when credential passing is > > attempted. The current implementation assumes and fails to check for > > ancillary data sizes other than 4 (credentials are of length 12). I > > believe it will be a relatively straight-forward task to add > > credential passing support similar to how file descriptor passing is > > done but it'll probably have to wait until the next Twisted release. A > > straight-forward work-around eludes me. > > > > Tom > > > > > > On Tue, Jul 3, 2012 at 8:16 AM, Tom Cocagne <tom.cocagne(a)gmail.com> > wrote: > >> I believe credential passing over Unix sockets is a new feature in > >> Twisted 12.1. The older versions I used to develop this project > >> didn't support that feature so I had to implement it myself. From the > >> stacktrace, I'm guessing that my workaround for this is clashing with > >> Twisted's new build-in support. I'll try and take a look at this in > >> the near future. > >> > >> Tom > >> > >> On Tue, Jul 3, 2012 at 5:27 AM, Tobias Oberstein > >> <tobias.oberstein(a)tavendo.de> wrote: > >>>> For anyone interested in taking a look, I've just released a > >>>> native-Python implementation of the DBus protocol for Twisted. The > >>>> intent of the implementation is to provide Twisted applications > >>>> with a full-featured DBus API that is consistent with the rest of > >>>> the framework and does not require the use of the glib reactor or libdbus > Python bindings. > >>> > >>> Cool! Also great work on the examples, tutorial and protocol overview! > >>> > >>> I'm having problems with the desktop notification example though .. any > hints? > >>> > >>> > >>> oberstet@ubuntu10bld_klon0:~/scm/twisted_dbus/doc/tutorial_examples$ > >>> ~/python273/bin/python -V Python 2.7.3 > >>> oberstet@ubuntu10bld_klon0:~/scm/twisted_dbus/doc/tutorial_examples$ > >>> uname -a Linux ubuntu10bld_klon0 2.6.32-41-generic #91-Ubuntu SMP > >>> Wed Jun 13 11:44:43 UTC 2012 i686 GNU/Linux > >>> oberstet@ubuntu10bld_klon0:~/scm/twisted_dbus/doc/tutorial_examples$ > >>> ~/python273/bin/python desktop_noficiation Unhandled Error Traceback > (most recent call last): > >>> File "/home/oberstet/python273/lib/python2.7/site- > packages/twisted/python/log.py", line 84, in callWithLogger > >>> return callWithContext({"system": lp}, func, *args, **kw) > >>> File "/home/oberstet/python273/lib/python2.7/site- > packages/twisted/python/log.py", line 69, in callWithContext > >>> return context.call({ILogContext: newCtx}, func, *args, **kw) > >>> File "/home/oberstet/python273/lib/python2.7/site- > packages/twisted/python/context.py", line 118, in callWithContext > >>> return self.currentContext().callWithContext(ctx, func, *args, **kw) > >>> File "/home/oberstet/python273/lib/python2.7/site- > packages/twisted/python/context.py", line 81, in callWithContext > >>> return func(*args,**kw) > >>> --- <exception caught here> --- > >>> File "/home/oberstet/python273/lib/python2.7/site- > packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite > >>> why = selectable.doRead() > >>> File "/home/oberstet/python273/lib/python2.7/site- > packages/twisted/internet/unix.py", line 169, in doRead > >>> fd = struct.unpack('i', ancillary[0][2])[0] > >>> struct.error: unpack requires a string argument of length 4 > >>> > >>> This is on Twisted 12.1 > >>> > >>> _______________________________________________ > >>> Twisted-Python mailing list > >>> Twisted-Python(a)twistedmatrix.com > >>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python(a)twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

1 0

[Twisted-Python] ANN: Twisted DBus 1.0
by Tom Cocagne July 4, 2012

July 4, 2012

For anyone interested in taking a look, I've just released a native-Python implementation of the DBus protocol for Twisted. The intent of the implementation is to provide Twisted applications with a full-featured DBus API that is consistent with the rest of the framework and does not require the use of the glib reactor or libdbus Python bindings. The project is currently hosted on github and has a pypi entry: https://github.com/cocagne/twisted_dbus http://pypi.python.org/pypi/twisted_dbus/1.0 Notes on the implementation: * A comprehensive tutorial and DBus protocol overview is included in the project documentation * Although the release version is set at 1.0, the project should be considered Beta quality as it has seen little real-world use * Unit test coverage is at about 98% * The code adheres to the Twisted coding standards * Windows is currently not supported (likely a trivially easy task but as yet unexplored) * Full, generated API documentation is possible but burnout/apathy set in before I figured out how to properly use Twisted's documentation generator * The implementation includes a basic DBus server implementation but, currently, it's only intended to serve as an alternative to the native DBus server when running the unit tests. Notes on Performance: * For a pure-python solution the performance is really quite good. * On the CPython interpreter, this implementation runs at about about 1/3 to 1/5th the speed of the libdbus bindings. * On the PyPy interpreter, this implementation runs at about the same speed as the libdbus bindings * Surprisingly enough, the bottleneck does not appear to be in the marshalling/unmarshalling routines. Simply compiling the dbus marshalling module with Cython yielded a 10x increase in marshalling performance but this translated into only a minor overall performance improvement. If anyone adept at Python/Twisted profiling would care to take a look, assistance in this area would be most welcome. - Tom Cocagne

5 11

Re: [Twisted-Python] Assigning AMP box senders & receivers from the responder
by Glyph July 4, 2012

July 4, 2012

Le Jul 4, 2012 à 12:39 AM, Laurens Van Houtven <_(a)lvh.cc> a écrit : > On 03 Jul 2012, at 23:53, Glyph wrote: > >> >> On Jul 3, 2012, at 12:08 AM, Laurens Van Houtven <_(a)lvh.cc> wrote: >> >>> I'm trying to implement a command called "Become" that allows a staff member to work as if he was the user himself. The most obvious way (to me at least) to do that to create the customer API (an IBoxReceiver/amp.BoxDispatcher subclass) for that customer (that'd normally be the Realm's job -- but since we're already logged in as an administrator, we don't go through Cred again), and hook up the current connection with that box receiver. Yay, code reuse! >> >> Why not just go through cred again? (If you look for 'Preauthenticated' in the Divmod code base you'll find that this is actually something of a design pattern.) > > I haven't seen that class, I'll take a look. > > I didn't want to go through fred again because I don't see the benefit. I'm not trying to do any authentication (that part's already done), admins don't know the relevant password, so it'd pretty much be IRealm.requestAvatar. I don't understand why portal, credentials checkers... come into play. Uh, hrm. Well, hypothetically the checker might have some extra knowledge about how to map a publicly visible user name into an avatar ID; avatar IDs aren't necessarily user names and in fact in the future I hope we can make them a bit more opaque. In many cases you're right though, it is the same. Really, this should just be a basic facility of cred so that protocols which need to communicate between authenticated users (SMTP, SIP, IRC, XMPP) can look up the relevant avatars without even having to think about what the right way to do it is :). >>> I don't see an obvious way to get a reference to the boxReceiver/boxSender from the responder method using documented APIs. Does this just mean I have to leak a reference to them all the way down? Am I doing something stupid? >> >> This is why the lowest level of argument parsing is fromString*Proto* rather than just fromString. You can write an Argument that doesn't actually look at the box and gives you any necessary properties from the protocol (or from the transport). It was originally written so you can ask for the host and peer addresses for P2P stuff, but this is another possible use. > > So what would this custom Argument be? Right now I take the user id of the user I'm trying to be. OK, I was definitely missing a couple of steps here. The custom Argument, in fromBox, can get a value from the CommandLocator, which is the 'protocol' in this case, because it's the CommandLocator which does the (de-)serialization. So it's not quite enough to just use that API. The docs here could stand to be improved - they say that this argument is an L{AMP} which is obviously wrong in your case. Basically you need to give your ComposedLocator knowledge of its BoxSender, which it needs to propagate to its component locators, so that you can ask for it later from the Argument. Given that I can see you might not want to mess with __init__, you can make this a separate method. (If you want to really continue in the spirit of AMP's component separation, make ComposedLocator be an IBoxReceiver as well - in fact, BoxDispatcher does what you want, so you can inherit from (or compose!) it; you automatically get a boxSender attribute, which will just so happen to point to the AMP instance whose boxReceiver you want to change. So, now your ComposedLocator has a boxSender, you can propagate it that value to its components as a public attribute and they can just mess with it on 'self'. But that's no fun, because now everybody in the whole system can just violate these layers whenever they want (although that is kind of what you want to do). So, what I was originally suggesting is that you can make everyone who wants to mess with the transport explicitly declare their intentions with a special argument type (as I originally suggested) by propagating it as a private attribute which ComposedLocator's layer of the code knows about. So, like this: class ComposedLocator(object): def startReceivingBoxes(self, boxSender): for locator in self._locators: locator._secretlyYouKnowAboutAMP = boxSender return super(ComposedLocator, self).startReceivingBoxes(boxSender) class ShowMeTheProtocol(Argument): def fromBox(self, name, strings, objects, componentLocator): objects[name] = componentLocator._secretlyYouKnowAboutAMP class Become(Command): arguments = [('boxSender', ShowMeTheProtocol())] Clear yet? :) >> Sorry I don't have time to be more expansive at the moment, I hope that's enough to get you un-stuck, > > Afraid not :( That's okay, I have different tests to go fix :) Don't we all.

1 0

[Twisted-Python] Assigning AMP box senders & receivers from the responder
by Laurens Van Houtven July 4, 2012

July 4, 2012

Hi, I have an AMP service that does cred-based auth with IBoxReceiver as the interface (see mantissa). On login, the user gets a different API depending if they're a staff member or not. Additionally, I wrote a composing IResponderLocator. It takes a bunch of responder locators and calls them in sequence to see if they can provide a responder. The reason it exists is because I want to put behavior in their separate, related modules, but @Command.responder is only supposed to work at class definition time. Here's the implementation: class ComposedLocator(object): """ A responder locator that consists of other locators. """ interface.implements(amp.IResponderLocator) class __metaclass__(type): def __new__(meta, name, bases, attrs): """ Makes sure every subclass gets its own set of locator classes. """ attrs["_locatorClasses"] = [] return type.__new__(meta, name, bases, attrs) def __init__(self, *args, **kwargs): self._locators = [l(*args, **kwargs) for l in self._locatorClasses] def locateResponder(self, name): """ Locates a responder from all the component responders. """ for locator in self._locators: responder = locator.locateResponder(name) if responder is not None: return responder @classmethod def component(cls, locatorClass): """ Registers a component locator. """ cls._locatorClasses.append(locatorClass) return locatorClass This has worked fine so far, but I've hit something so annoying to fix that I'm wondering if I'm not doing something very stupid and overlooking the obvious. I'm trying to implement a command called "Become" that allows a staff member to work as if he was the user himself. The most obvious way (to me at least) to do that to create the customer API (an IBoxReceiver/amp.BoxDispatcher subclass) for that customer (that'd normally be the Realm's job -- but since we're already logged in as an administrator, we don't go through Cred again), and hook up the current connection with that box receiver. Yay, code reuse! Except, no. Because of the composed locator detailed above, the responding method has no reference to the box sender and box receiver. It's it's own little standalone object, with barely any AMP-specific knowledge. Ordinarily elegant, now annoying. The only reason it ever worked before is because the default AMP implementation basically just involves subclassing everything into one object (self is self.boxReceiver is self.boxSender) I don't see an obvious way to get a reference to the boxReceiver/boxSender from the responder method using documented APIs. Does this just mean I have to leak a reference to them all the way down? Am I doing something stupid? cheers lvh

2 2

[Twisted-Python] txWS !!
by vinod kumar July 1, 2012

July 1, 2012

Hi, Thanks a lot for your reply. The trouble is that the events I have are triggered by a homematic CCU. The CCU does it by multicall which has not yet been implemented in twisted servers. So, I'm running a non-twisted xmlrpc server in a thread so that my CCU triggers the events and it's happening too. I can see the events printed on the console too. Now, I just want a way to write the same to sockets. Can't we connect these to txWS factory ? Doesn't the txWS has some socket object so that we can just say socket.write..hmm Thanks, Vinodh ------------------------------------------------------------------- Hi Vinodh, txWS merely lets you connect to a Twisted Factory through WebSockets. You will still need to structure your code such that the events that you are responding to are connected to that Factory. It might be helpful to rewrite your XML-RPC server to use Twisted's XML-RPC (see http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html for a tutorial on that) and then it will be easier to hook up your events without having to worry about threading or other blocking things. If you're having specific problems with txWS, let me know; it's important to us that txWS work smoothly for people using it. ~ C. ------------------------------- On Fri, Jun 29, 2012 at 04:52:06PM +0200, vinod kumar wrote: > Hi All, > > I have run and edited the example provided for txWS. The writing part > from server to client browser is shown only as self.transport.write() > inside dataReceived function in websockets.py. how do I write on to the > socket i.e. on to the browser, from a different function inside server > code(server.tac). I'm just starting another xmlrpc server on a thread where > I receive some notifications. I need to forward the same to socket. The > bold point below is where I want to write on to socket. How can we do > that? Please help me out. > ------------------------------------------------------- > import time > > from twisted.internet import reactor > from twisted.application import internet > from twisted.application.service import Application, Service > import xmlrpclib > from txws import WebSocketFactory > > from src.protocols.websockets import WebSocketServerFactory > from constants import * > > class WebSocketService(Service): > """ > A simple service that listens on port 8077 for WebSockets traffic. > """ > def __init__(self): > self.start_time = time.time() > > def start_service(self, application): > """ > Gets the show on the road. Fires up a factory, binds the port. > """ > echofactory = WebSocketServerFactory(self) > factory = WebSocketFactory(echofactory) > ws_server = internet.TCPServer(8077, factory) > ws_server.setName('ws-tcp') > ws_server.setServiceParent(application) > > def shutdown(self): > """ > Gracefully shuts down the service. > """ > reactor.callLater(0, reactor.stop) > > def listDevices(id): > print "listDevice: %(id)s" % {"id": str(id)} > return None > > def event(id, address, key, value): > #websocket.send("ufffffffffuuuuuu") > * #I need to write the below print statement on to browser * > print "event: %(id)s: %(address)s: %(key)s = %(value)s" % {"id": > str(id), > "address": str(address), "key": str(key), "value": str(value)} > > def aSillyBlockingMethod(x): > import time > import xmlrpclib > time.sleep(2) > from SimpleXMLRPCServer import SimpleXMLRPCServer > from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler > from constants import * > server = SimpleXMLRPCServer((SERVER_IP, SERVER_PORT), logRequests=True, > allow_none=True) > server.register_introspection_functions() > server.register_multicall_functions() > print "server started at %s" % str(SERVER_URL) > server.register_function(listDevices) > server.register_function(event) > print 'function also got registered' > server.serve_forever() > .............................continues > > Thanks, > Vinodh

2 2

[Twisted-Python] Weekly Bug Summary
by exarkun＠twistedmatrix.com July 1, 2012

July 1, 2012

1 0