Make foolscap forward-compatible with Twisted Endpoints

[str4d]

As part of the switch to using Endpoints in ticket:203, foolscap needs to understand connection strings in the ​Twisted Endpoints syntax. Current foolscap only accepts TCP connections (and assumes that old-style "host:port" connection hints are TCP). Foolscap should therefore understand and accept TCP Endpoints strings in the connection hints, and ignore all others (so it is not confused or broken by other Endpoint string types).

As requested by zooko in ticket:203#comment:28.

[str4d]

First patch for this has been merged (​https://github.com/warner/foolscap/pull/15) but is incomplete, because it assumes that the Twisted Endpoints syntax only allows for keyword arguments.

[str4d]

Follow-up pull request with support for all possible parameter permutations: ​https://github.com/warner/foolscap/pull/17

[dawuud]

Greetings.

Recently, I attempted to port foolscap to using twisted endpoints... at least for the client side of the connection. I was unaware of this ticket when I wrote this: ​https://github.com/david415/foolscap/commit/2fa6e1c399d8a46ed702310a5b7c5bfe566fb641

There were a few unit tests that fail in my branch at that commit. I think these might be caused by the connect deferred behaving differently than the IConnector.

But there is another problem I wanted to talk about and volunteer to fix... (i will demonstrate with a git branch soon and then report back here) decode_furl returns a tuple which contains location_hints; currently this is a list of 3-tuples (type, host, port). I think instead location_hints should be a list of strings. The strings would be the twisted endpoint string. Old style hints can be converted into new style hints... or if no match then rejected.

TubConnector? connectToAll needs to have whole endpoint descriptor in order to build the endpoint correctly. For instance if we want our foolscap connections to be over a socks proxy then we need to specify the socks_host, socks_port, dest_host, dest_port...

[dawuud]

str4d, I'll help out with this. What's the next step?

[dawuud]

My endpoints branch: ​https://github.com/david415/foolscap/tree/endpoints demonstrates what I'm talking about... also this commit here: ​https://github.com/david415/foolscap/commit/759aced4ee2fd52d2a66549daba09af7109a63eb

However some tests are failing... and so now I'm trying to track down the problems... and fix them.

[dawuud]

ok i'm going to continue this on trac ticket #203 ​http://foolscap.lothar.com/trac/ticket/203

[Zooko]

Good discussion of the state of Tahoe-LAFS-over-Tor: ​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:15

[str4d]

Replying to dawuud:

ok i'm going to continue this on trac ticket #203 ​http://foolscap.lothar.com/trac/ticket/203

Yes, this ticket is solely for a release of foolscap that will not break when later versions start using whatever FURLs are used for Endpoints.

[Brian Warner]

The patch in ​https://github.com/warner/foolscap/pull/17 looks pretty close. The only real concern (noted there) is that it uses private/internal Twisted functions, and we should really stick to public interfaces. Once we've resolved that, I'll land it, and I think that means we can close this ticket.

[Brian Warner]

Landed, in [1b815bb6e5c4ab47dbf3d60d2a9188c9427a9dfb]. Thanks!