Opened 4 years ago

Last modified 4 years ago

#2090 accepted enhancement

i2p.streaming.* options don't work from router.config

Reported by: Zlatin Balevsky Owned by: zzz
Priority: minor Milestone: undecided
Component: streaming Version: 0.9.32
Keywords: Cc:
Parent Tickets: Sensitive: no


The various streaming connection options should be settable in router.config, but only work if set in wrapper.config.


Change History (3)

comment:1 Changed 4 years ago by Zlatin Balevsky

Type: defectenhancement

Marking this as an enhancement because there never was any plumbing to make !I2PSocketManager work with settings stored in router.config

comment:2 Changed 4 years ago by zzz

Owner: set to zzz
Status: newaccepted

Preferred method now is per-tunnel via custom options in i2ptunnel edit form.

Will have to research the history to see if we intended to support router.config or not, did we change it, and why.

comment:3 Changed 4 years ago by zzz

This is complex because we have properties/options for System, the router, the app context, i2ptunnel task, the i2p session, the socket manager, the connection, and the socket. I've fallen down this hole many times before and it isn't pretty.

The use of System.getProperties() as defaults to populate the ConnectionOptions?, I2PSocketOptionsFull and I2PSocketManagerFull options seems to be a jrandom thing dating back to 2004.

There's no attempt to populate the options with all the context properties in streaming or ministreaming at all. This is probably because, on the I2PAppContext side, there's no facility for reading in defaults from a file.

Within RouterContext?, of course, we have router.config.

On the i2ptunnel side, I did add a population of the options from the context to the I2PTunnel constructor long ago in 0.8.4. But in I2PTunnel.setClientOptions(), we remove properties that aren't set. I believe this is because we don't want to pull all the context options back into the I2PTunnel edit form custom options block, or save them into i2ptunnel.config.

ConnectionOptions? is also a mess with four different constructors with different flavors of options passed in, and the I2PSocketManagerFull.buildOptions() call that copies everything.

In addition, there's the note at the top of ConnectionOptions? that a lot of the options don't belong there, as they aren't per-connection options at all. We really need to split those out into socket manager options.

Notwithstanding all of the above, if we wanted to fix this we'd probably want to check the context property in two places, ConnectionOptions?.getBool() and I2PSocketOptionsImpl.getInt(). Or stuff them all in, in I2PSocketManager.buildOptions(). That would get almost everything. To do it at any higher level would not pick up changes made to the context properties while testing, you would need to restart the tunnel or the whole router if we only checked in the socket manager or i2ptunnel.

We may want to do this as a part of splitting up ConnectionOptions?, to reduce the amount of code and memory it takes, for _every_ socket, to create the ConnectionOptions? for it.

Note: See TracTickets for help on using tickets.