[Twisted-Python] Status of current proxy support (of various kinds)
kevin.horn at gmail.com
Tue Aug 9 12:17:43 EDT 2011
Also, anyone working on socks5 in twisted should be aware of this project:
which implements a SOCK5 server. It's in the context of a Jabber/XMPP
XEP-0065 proxy server, but a lot of it should be applicable, if just as an
I make no guarantees about the quality and/or correctness of the code, as
I've only skimmed it a couple of times. I do know it predates the endpoint
API, and I doubt it has been updated.
(getting SOCS5 support into twisted has been on my 'maybe someday" todo
list, and I was planning on looking at this in more detail as a reference).
It's MIT licensed.
On Mon, Aug 8, 2011 at 11:31 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>wrote:
> On Aug 8, 2011, at 10:10 PM, Peter Le Bek wrote:
> > Myself and another are working on adding SOCKS client support to Twisted
> > use in Tor related projects. I'm also convinced there's an abstraction
> that would
> > make it easier to implement proxy clients (or any transparent
> > modifying protocol) in Twisted. I agree that it's difficult to
> generalise, but there's a
> > class of protocol that does one or more of the following, transparently,
> and little
> > else:
> > - append data, before switching to application protocol (SSL handshake,
> SOCKS connect/bind)
> > - prepend data, after losing connection on application protocol (SSL
> > - modify application data (SSL "recordification", encryption)
> > - modify the endpoint (any proxy)
> > Endpoints can do all these things - SSL4ClientEndpoint, for example, does
> the first
> > three - but does it make sense to use Endpoints for this purpose?
> I think so.
> > Endpoints aren't stackable, so no good if I want to run a SOCKS client
> over SSL.
> Sure they are. There's no SOCKS endpoint yet, but if you were to implement
> one, you could make it take another endpoint (or endpoint factory, as the
> case may be) as an argument to its constructor. The implementation of the
> various current SSL* enpdoints would set a better example if it weren't for
> the legacy connectSSL/listenSSL APIs. However, those APIs are being slowly
> phased out in favor of the endpoints themselves, as well as the internal
> implementation being moved to use a wrapping / delegation approach <
> http://twistedmatrix.com/trac/ticket/4854> between transports and
> protocols instead of OpenSSL's SSL-is-a-socket-except-when-it-isn't
> > Also, with a proxied connection you have two Endpoints, one to the proxy
> > and one 'virtual Endpoint' to wherever. The Endpoints API doesn't
> > this.
> How doesn't it? It's exactly this kind of API that endpoints were
> _designed_ to accommodate - the original impetus to create them was the
> Vertex project (now part of <https://launchpad.net/divmod.org/>), which
> proxies traffic in a variety of different ways.
> > Would it make sense to have Endpoint wrappers for this purpose? A sort of
> > middleware (hate that word) to intercept transport events (including
> > formation, i.e. Endpoint.connect()).
> It might make sense to have some utilities around this area. There are
> definitely parts of the process - especially producers and consumers - where
> you have to write a lot of boilerplate code to make sure everything's hooked
> up properly. But it's all certainly _possible_ now with the existing
> You'd probably be interested in this ticket: <
> http://twistedmatrix.com/trac/ticket/3204>. Perhaps you could submit a
> patch? :)
> > I'm looking forward to being proven wrong on this as it will make my
> SOCKS work
> > easier, or else if this turns out to be interesting then I have more
> ideas on how it
> > should be implemented.
> It would help with that proof if you would be a bit more precise about
> where you think the current code falls short.
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python