-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace the implementation of IReactorSSL with one based on twisted.protocols.tls #4854
Comments
(In [30792]) Branching to 'protocol-ssl-4854' |
|
Replying to itamar:
"pyOpenSSL branches"? This is a feature of a pyOpenSSL release, not an experimental development thing. Version 0.10, which includes the requisite feature, was released over a year ago. Since then, 0.11 has come out. Newer versions of software have newer versions of dependencies. Packagers will notice and upgrade as necessary; For what it's worth though, Ubuntu Maverick packages 0.10, and so Ubuntu and its derivatives (and probably Debian too) area already caught up.
If it's broken for them then maybe they should report bugs in it and we can fix them. We already have so many mechanisms in place to prevent regressions - unit test coverage, pre-release testing, buildbots on a dozen different platforms, a stable trunk that users can experimentally deploy on without too much worry - we should be fearless in releasing changes like this. If we need a whole slew of new tests in order to really be sure it's not broken and get better coverage, then that's fine (although I don't think we do), but there's no need to be cagey about releasing a feature that has passed our QA bar. Those are the general arguments, but in this case we also have a specific argument. There are presumably people using iocpreactor with SSL (because there was a fair amount of interest in that ticket) and so this functionality has already been receiving real-world testing (in addition to the aforementioned unit test coverage and prerelease testing), and I haven't heard about significant problems with it yet. Also, a major motivation for doing this ticket is to reduce the amount of code in Twisted and the complexity of the transport implementations. If we just switch over the endpoint implementations, we can't get rid of the code in the guts of the reactor and Of course, maybe another point that got lost in the noise - should we just get rid of |
Squeeze (stable) has 0.10, indeed. I thought about making the implementation fall back to the old code if pyOpenSSL isn't new enough. This would be easy for
Another motivation is that there's a really obscure bug in the current implementation that is most obviously fixed by replacing it with the
Ultimately, but I think this can wait a few more years. Everyone should be happily using endpoint APIs before we consider this.
This might be a good use-case for non-str-based protocol interfaces. If we could move buffers (or other non-copying-based data structures) around, that should take care of the only (hypothetical) point of inefficiency in |
Latest checkin has incomplete sentence: "- a C{_tlsClientDefault} attribute indicating". |
(In [30899]) Branching to 'protocol-ssl-4854-2' |
(In [31214]) Branching to 'protocol-ssl-4854-3' |
|
This only requires a newer version of pyOpenSSL, not of OpenSSL, right? If someone's gonna upgrade Twisted on an old distro, I don't see much issue also upgrading pyOpenSSL to go with it. |
(In [31269]) Branching to 'protocol-ssl-4854-4' |
I tend to agree. But I didn't see your comment until after I mostly implemented the fallback for older versions. |
|
I forced a rebuild here - http://buildbot.twistedmatrix.com/builders/windows7-64-py2.7/builds/344 - and it failed again in exactly the same way. Curiously, it fails on the select reactor, but not on the IOCP reactor. It's too bad about the Windows thing, because everything else was pretty cosmetic. If you can figure that one out, then it should probably be landed, although a test failure with unknown functional changes to fix necessitates a re-review. Please link to the revision from your re-review comment though, as that will (hopefully) be easy to review on its own. |
Done in r31367 and r31372. Followup fix in r31373 to fix the markup.
Done in r31369
Done in r31370
Filed #4974
I agree. They're asserts in trunk, though. I filed #4975 for addressing them.
Fortunately, it was nothing horrible at all. The failing test,
On Windows with Now that the reactor prefers Here are the latest build results. |
The patch looks good, but... while testing this with calendar server, I saw this at the bottom of a bunch of tracebacks when I stress-tested it by making tons of SSL connections. (I haven't done any other testing yet, not sure if I can reproduce this with just Twisted itself.)
Any idea what that might be about? |
Replying to exarkun:
Refresh my calendars a few times in succession, or, type in an I think it may have something to do with connections being dropped by the client before the server thinks the negotiation has finished...? |
(In [31398]) Branching to 'protocol-ssl-4854-5' |
(In [31478]) Branching to 'protocol-ssl-4854-6' |
Okay, one more time!
|
Oh yes. Also, I did not fix the CalendarServer problem. CalendarServer is poking around in reactor internals. I think this implementation simplification (weeeeell it'll be a simplification eventually, when we drop support for pyOpenSSL <0.10) is more important than supporting extremely obscure uses of internal reactor APIs. It should be an easy change to CalendarServer to avoid the problem, and the problem is very minor since it is only logging an error in a case where data is being discarded, as opposed to silently discarding that data as it used to do. |
Some doc stuff:
What about
|
Hm. It's private. I think @SInCE markers are mostly for public APIs so developers know what minimum version of Twisted they will need if they use them. On the other hand, it doesn't hurt (for the module level, at least).
I think it's correct as it is. "have" agrees with the plural subject, "requirements" (though putting a verb before a ":" is traditionally considered bad form, but I never really agreed with that :).
I added docstrings for the truly new classes (and made them new-style). I left the old classes, which merely moved to a new module, undocumented. Documenting them understandably would be quite a challenge, plus what they do almost doesn't make sense anyway (shuffling
I changed it in another way, hopefully that reads better. Last three points fixed as well. Thanks for the review! |
Replying to exarkun:
What do you mean by "the Calendar Server problem"? There's the warnings and there's the traceback; I wouldn't expect you to fix the warnings, but I think the traceback is worth addressing. I think it's slightly misleading to call this an "extremely obscure use of internal reactor APIs". The use-case here is to distribute load between different processes on the same system to make use of multiple cores. That's a pretty common desire, I think. There's no nice, neat public API way to do it. We should definitely fix Calendar Server to do it better (although I'm still not completely clear on how to do that...) but we also need to have documentation that explains how it should be done, before the only semi-obvious way to do it starts emitting tracebacks. Of course you could contribute a fix to Calendar Server to address the problem or absorb the code from Calendar Server into Twisted somewhere and my objections would go away ;). Basically, I agree that these are reactor internals, but we should go through the process of fully deprecating all of |
Okay. I fixed things so Calendar Server's usage works. Apple should get motivated about implementing some APIs so this can be done in a more reasonable manner, though. ;) |
This looks pretty good; I looked at the Calendar Server issue under both PyOpenSSL 0.10
The implementation looks good though. The only actually functional suggestion |
Done, http://twistedmatrix.com/trac/changeset/31536#file1
If not now, then it'll just be later. :) I filed #5014.
Done, change also visible at http://twistedmatrix.com/trac/changeset/31536#file1
Hmmm. Yes. Filed #5015.
I suppose. I don't care so much about this either way though. It will go away when we resolve #5015, after all.
Done, see http://twistedmatrix.com/trac/changeset/31536#file0 (
Done, see http://twistedmatrix.com/trac/changeset/31536#file4
Hmm. Yea maybe... But this class shouldn't pretend to be a general purpose socket fake. It does what is necessary for the few tests that use it now. I guess we should have a ticket for making it a general purpose fake, but I'm hesitant for some reason...
Done, change is visible at the bottom of http://twistedmatrix.com/trac/changeset/31536#file4
Filed #5016.
Done, see http://twistedmatrix.com/trac/changeset/31536#file2
#5014 proposes a timeline now. I think having it in a milestone is a good idea, too. |
(In [31537]) Merge protocol-ssl-4854-6 Author: exarkun Add an implementation of This appears to have slightly better performance than the old implementation and |
The original implementation of
IReactorSSL
, shared amongst all reactors except for IOCP reactor, lets OpenSSL do all of the network operations, because that was the only way the pyOpenSSL bindings let them work.More recently, pyOpenSSL began exposing an alternate OpenSSL API, which we now support in
twisted.protocols.tls
. This API lets us do all of the network operations and limits OpenSSL to just the crypto parts.Finally, a benchmark shows that
twisted.protocols.tls
is actually comparable in performance to theIReactorSSL
interface.Since
twisted.protocols.tls
provides a struct superset of the functionality ofIReactorSSL
, we could implement the latter in terms of the former, removing some code in the process.One possible issue is that pyOpenSSL 0.10 or newer is required for
twisted.protocols.tls
. This version of pyOpenSSL is a little over a year old, but may not yet be in widespread use. Possibly we should start by preferring atwisted.protocols.tls
implementation ofIReactorSSL
, but falling back to the current implementation if necessary (for a while).Searchable metadata
The text was updated successfully, but these errors were encountered: