tahoe-lafs/trac-2024-07-25

i2p options, `tub.port = listen:i2p` #2889

New issue

Closed

opened 2017-07-12 16:02:22 +00:00 by warner · 2 comments

warner commented

2017-07-12 16:02:22 +00:00

Owner

PR 415 adds a --i2p-i2cp-options= flag to the tahoe create-node CLI command, and stores these options in the tahoe.cfg file under i2p i2cp.options=, and arranges to use these options when creating the SAM socket.

It must also store these options in the node tub.port= field, since the SAM socket might be created by the Tub listener or the outbound connection handler, and the I2P server will stick with the options requested by whichever one arrives first. So to avoid a race, we must use exactly the same options in both places.

This is complicated by the fact that tub.port is first parsed as a comma-joined list of listener descriptors, then each element is parsed as an Endpoint descriptor (which means splitting on colons). Since the I2CP options are a dictionary, encoded with colons and commas, there's a lot of escaping and de-escaping going on.

In yesterday's devchat, we decided that it would be cleaner to put these options solely in the i2p i2cp.options= field (where they don't need escaping), and not try to put them in tub.port. This DRY (Don't Repeat Yourself) approach avoids the question of what happens if the two option-setting keys disagree, and removes the quoting/escaping concern.

To accomplish this, we decided to change the tub.port semantics slightly. It normally contains a comma-separated list of Endpoint descriptors, each of which starts with a TYPE: prefix and then a list of colon-separated arguments for that type of endpoint. We're comandeering the listen: "type" to mean "ask the tahoe 'provider' for that type to contribute some Server Endpoints". The provider will also be asked for one or more Foolscap connection hints, to add to tub.location.

So tub.port = listen:i2p means "ask the i2p_provider for an endpoint". tub.port = tcp:12345,listen:i2p,listen:tor will get one static TCP endpoint, plus whatever I2P wants to use, plus whatever Tor wants to use.

The code in Node.create_main_tub() that handles tub.port will look for the listen: prefix and call out to the provider, rather than passing the raw string into tub.listenOn(). Once the provider returns a list of Endpoints, they'll be passed one-at-a-time into tub.listenOn().

If Twisted (or any active plugins) add an endpoint type named "listen", this will prevent them from being used, but that doesn't seem too likely. We could pick a tahoe-specific name to avoid this, but I think that would be harder to read (e.g. tub.port = tahoe-listen:i2p). I'm not sure, though.

The i2p_provider will then have a method to return a fully-formed Endpoint, with the I2CP options baked in, instead of trying to shoehorn these options into a string that's then passed to endpoints.serverFromString.

We'll close PR415 in favor of a different one that adds these changes.

[PR 415](https://github.com/tahoe-lafs/tahoe-lafs/pull/415) adds a `--i2p-i2cp-options=` flag to the `tahoe create-node` CLI command, and stores these options in the tahoe.cfg file under `i2p i2cp.options=`, and arranges to use these options when creating the SAM socket. It must also store these options in the `node tub.port=` field, since the SAM socket might be created by the Tub listener *or* the outbound connection handler, and the I2P server will stick with the options requested by whichever one arrives first. So to avoid a race, we must use exactly the same options in both places. This is complicated by the fact that `tub.port` is first parsed as a comma-joined list of listener descriptors, then each element is parsed as an Endpoint descriptor (which means splitting on colons). Since the I2CP options are a dictionary, encoded with colons and commas, there's a lot of escaping and de-escaping going on. In yesterday's devchat, we decided that it would be cleaner to put these options solely in the `i2p i2cp.options=` field (where they don't need escaping), and not try to put them in `tub.port`. This DRY (Don't Repeat Yourself) approach avoids the question of what happens if the two option-setting keys disagree, and removes the quoting/escaping concern. To accomplish this, we decided to change the `tub.port` semantics slightly. It normally contains a comma-separated list of Endpoint descriptors, each of which starts with a `TYPE:` prefix and then a list of colon-separated arguments for that type of endpoint. We're comandeering the `listen:` "type" to mean "ask the tahoe 'provider' for that type to contribute some Server Endpoints". The provider will also be asked for one or more Foolscap connection hints, to add to `tub.location`. So `tub.port = listen:i2p` means "ask the i2p_provider for an endpoint". `tub.port = tcp:12345,listen:i2p,listen:tor` will get one static TCP endpoint, plus whatever I2P wants to use, plus whatever Tor wants to use. The code in `Node.create_main_tub()` that handles `tub.port` will look for the `listen:` prefix and call out to the provider, rather than passing the raw string into `tub.listenOn()`. Once the provider returns a list of Endpoints, they'll be passed one-at-a-time into `tub.listenOn()`. If Twisted (or any active plugins) add an endpoint type named "listen", this will prevent them from being used, but that doesn't seem too likely. We could pick a tahoe-specific name to avoid this, but I think that would be harder to read (e.g. `tub.port = tahoe-listen:i2p`). I'm not sure, though. The `i2p_provider` will then have a method to return a fully-formed Endpoint, with the I2CP options baked in, instead of trying to shoehorn these options into a string that's then passed to `endpoints.serverFromString`. We'll close PR415 in favor of a different one that adds these changes.

tahoe-lafs added the

labels 2017-07-12 16:02:22 +00:00

tahoe-lafs added this to the soon milestone 2017-07-12 16:02:22 +00:00

Brian Warner <warner@lothar.com> commented

2017-11-03 07:47:11 +00:00

Author

Owner

In 097abb4/trunk:

tahoe.cfg: add tub.port=listen:i2p (and/or listen:tor)

This delegates the construction of the server Endpoint object to the i2p/tor
Provider, which can use the i2p/tor section of the config file to add options
which would be awkward to express as text in an endpoint descriptor string.

refs ticket:2889 (but note this merely makes room for a function to be
written that can process I2CP options, it does not actually handle such
options, so it does not close this ticket yet)

In [097abb4/trunk](/tahoe-lafs/trac-2024-07-25/commit/097abb42fa117b54fbfcbaaae02d3836386f2ece): ``` tahoe.cfg: add tub.port=listen:i2p (and/or listen:tor) This delegates the construction of the server Endpoint object to the i2p/tor Provider, which can use the i2p/tor section of the config file to add options which would be awkward to express as text in an endpoint descriptor string. refs ticket:2889 (but note this merely makes room for a function to be written that can process I2CP options, it does not actually handle such options, so it does not close this ticket yet) ```

warner commented

2017-11-03 07:50:29 +00:00

Author

Owner

done

tahoe-lafs added the

fixed

label 2017-11-03 07:50:29 +00:00

warner closed this issue

2017-11-03 07:50:29 +00:00

tahoe-lafs modified the milestone from soon to 1.13.0

2017-11-03 07:50:42 +00:00