[Twisted-Python] M2Crypto+Twisted, part 2
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.
On Tue, 07 Dec 2004 17:46:52 -0800, Heikki Toivonen heikki@osafoundation.org wrote:
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:
You should call proto.transport.loseConnection() instead of proto.connectionLost(). The former indicates to the reactor that the connection should be dropped, the latter is a callback that the reactor invokes to tell you that the connection has been dropped.
Jp
Jp Calderone wrote:
On Tue, 07 Dec 2004 17:46:52 -0800, Heikki Toivonen heikki@osafoundation.org wrote:
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...
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:
You should call proto.transport.loseConnection() instead of proto.connectionLost(). The former indicates to the reactor that the connection should be dropped, the latter is a callback that the reactor invokes to tell you that the connection has been dropped.
Ok, that makes the exception go away, but it still does not solve the problem why I tried to use connectionLost() in the first place. I want to signal that this connection was lost because of an error, and calling loseConnection() won't let me specify the error.
I am looking at as non-invasive methods as possible, the ultimate goal being that you could hook this up to any existing non-SSL implementation with practically no changes. That seems to rule out custom errbacks.
So, when my wrapper notices an SSL error, how do I signal that the connection should be dropped because there was an error - and pass some info about the error along?
On Wed, 2004-12-08 at 11:45 -0800, Heikki Toivonen wrote:
So, when my wrapper notices an SSL error, how do I signal that the connection should be dropped because there was an error - and pass some info about the error along?
Perhaps we could add an optional exception or maybe failure keyword arg to loseConnection (and abortConnection when we have that).
On Wed, 2004-12-08 at 11:45 -0800, Heikki Toivonen wrote:
So, when my wrapper notices an SSL error, how do I signal that the connection should be dropped because there was an error - and pass some info about the error along?
Aren't you calling the user protocol's connectionLost yourself? You could remember the reason (if you did) that you closed connection, and pass that.
participants (3)
-
Heikki Toivonen -
Itamar Shtull-Trauring -
Jp Calderone