A while back I integrated M2Crypto into Twisted, but the architecture was not deemed good then (it was adding more of the SSL cruft in tcp.py etc.). James Knight pointed me to TLS Lite, which had achieved similar functionality by using ProtocolWrapper and WrappingFactory and all the code was outside of Twisted. (Thanks James!) I've now got an implementation of M2Crypto + Twisted integration using the TLS Lite approach - no changes in Twisted required. (Client only for now and not yet fully cleaned up, but all the important pieces should be there.) However, I've run into some problems and I am not sure if they are bugs in Twisted or if I am using these interfaces wrong. Maybe you can help. The most interesting piece of the code is my TLSProtocolWrapper that inherits from ProtocolWrapper. See http://lxr.osafoundation.org/source/internal/m2crypto/M2Crypto/SSL/TwistedPr... Now, this seems to works perfectly with the echoclient samples when the SSL connection has no errors. When there is an error in the SSL connection, and I call connectionLost(), I end up with a traceback that feels like it might be a Twisted bug. Or if I am not allowed to call that, how do I signal that I want to break the connection? Here's the traceback: Traceback (most recent call last): File "twisted_ssl/real.py", line 71, in main reactor.run() File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\intern et\default.py", line 123, in run self.mainLoop() File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\intern et\default.py", line 134, in mainLoop self.doIteration(t) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\intern et\default.py", line 529, in doSelect _logrun(selectable, _drdw, selectable, method, dict) --- <exception caught here> --- File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\python \log.py", line 65, in callWithLogger return callWithContext({"system": lp}, func, *args, **kw) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\python \log.py", line 52, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\python \context.py", line 43, in callWithContext return func(*args,**kw) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\intern et\default.py", line 552, in _doReadOrWrite selectable.connectionLost(f) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\intern et\tcp.py", line 452, in connectionLost Connection.connectionLost(self, reason) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\intern et\tcp.py", line 295, in connectionLost protocol.connectionLost(reason) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\M2Crypto\SSL\T wistedProtocolWrapper.py", line 207, in connectionLost ProtocolWrapper.connectionLost(self, reason) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\protoc ols\policies.py", line 88, in connectionLost self.factory.unregisterProtocol(self) File "c:\builds\chandler\chandler\release\bin\lib\site-packages\twisted\protoc ols\policies.py", line 127, in unregisterProtocol del self.protocols[p] exceptions.KeyError: <twisted.internet.tcp.Client to ('www.verisign.com', 443) a t 10fa800> When I try to hook this up into an IMAP4 client, it seems like my wrapper is getting bypassed somewhere. With debug on, I see: MyProtocolWrapper.__init__ MyProtocolWrapper.makeConnection MyProtocolWrapper.connectionMade then nothing, until the connection finally times out. I haven't looked much into this one yet. Any guesses as to where I should be looking at? Or is it not possible to use the ProtocolWrapper here? I can upload full source packages as well if anyone needs them. -- Heikki Toivonen